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I.  INTRODUCTION 


1. 1  Purpose.  The  primary  purpose  of  this  Software  Design  Manual  is  to 
provide  an  organized  plan  for  the  development  of  software  for  the  South¬ 
western  Division  (SWD)  Water  Contro  Data  System  (WCDS).  It  will: 

a.  Present  water  managers  (users)  requirements  for  the  WCDS. 

b.  Identify  the  software  necessary  to  satisfy  the  user  require¬ 
ments  for  water  management. 

c.  4ct  as  guidance  for  detailed  software  design  methods. 

d.  Provide  a  schedule  and  management  tool  for  software  develop¬ 
ment  . 

1.2  Relation  to  WCDS  Master  Plan.  The  SWD  WCDS  Master  Plan,  approved 
in  1979,  detailed  system  performance  requirements,  described  and  evalu¬ 
ated  alternative  approaches  to  meet  those  requirements  and  recommended  a 
system  plan.  The  system  plan  included  computer  hardware,  peripheral 
hardware  (disc  &  tape  drives,  printers,  terminals  communications  hard¬ 
ware),  software  and  compilers,  remote  gaging  station  telemetry  via 
satellite  and  communications  system  interface.  The  Software  Design 
Manual  is  an  extension  of  the  SWD  WCDS  Master  Plan  to  provide  for  an 
orderly  development  of  user  software  for  the  system. 

1.3  Purpose  of  the  WCDS.  The  SWD  WCDS  is  comprised  of  all  of  the 
equipment  within  the  division  used  to  acquire,  process,  display  and  dis¬ 
tribute  information  for  real-time  project  regulation  and  associated  in¬ 
teragency  coordination.  Its  purpose  is  to  provide  a  cost  effective 
means  of  collecting,  distributing,  analyzing  and  displaying  data  re¬ 
quired  by  the  water  managers  for  day-to-day  regulation  of  more  than  110 
Corps  and  Section  7  reservoirs  within  SWD. 
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II. 


SWD  WATER  CONTROL  MANAGEMENT 


2 . 1  Geographical  Area. 

2.1.1  General .  The  SWD  Corps  of  Engineers  geographical  area  of 
responsibility  covers  557,000  square  miles  which  includes  all  of 
Oklahoma,  all  of  Texas,  all  of  New  Mexico  east  of  the  Continental 
Divide,  and  parts  of  Arkansas,  Missouri,  Colorado,  Kansas  and  Loui¬ 
siana.  The  division  Is  divided  Into  five  districts:  Albuquerque, 
Fort  Worth,  Galveston,  Little  Rock  and  Tulsa.  The  area  encompassed 
contains  widely  diverse  geographical  and  climatic  conditions.  This 
diversity  presents  a  broad  range  of  water  management  problems  re¬ 
quiring  a  water  control  data  collection  and  management  system  which 
has  the  flexibility  to  adapt  to  the  various  district  differences 
and  also  fulfill  the  requirements  of  a  divisionwide  system. 

2.1.2  Topography.  The  western  portion  of  the  division  is  bounded 
by  the  Continental  Divide  in  the  rugged  Rocky  Mountains  of  Colorado 
and  New  Mexico.  Streams  flow  through  deep  gorges  and  narrow  val¬ 
leys  enroute  to  the  Great  Plains  to  the  east  or  large  central  val¬ 
leys  to  the  south.  The  northern  portion  is  bounded  by  the  plains 
area  and  the  Ozark  highlands.  The  plains  are  rolling  prairies  with 
rich  farmlands  and  pasture  while  the  Ozark  highlands  are  rugged  and 
largely  forested.  On  the  east  is  the  Grand  Prairie,  the  Mississip¬ 
pi  alluvial  valley  and  the  rolling  piney  woods  area  along  the 
Texas/Louisiana  border.  The  southern  boundary  is  the  Gulf  Coast 
with  relatively  flat  coastal  plains,  then  along  the  Rio  Grande  from 
the  fertile  lower  valley  to  the  rugged  Big  Bend  country.  The  in¬ 
terior  areas  of  the  division  vary  from  the  rugged  Sangre  de  Cristo 
Mountains,  to  the  gently  rolling  plains  of  north-central  Texas. 
Streams  vary  from  steep,  narrow  channels  with  rapid  runoff  to  flat 
streams  with  sluggish  flows  and  shifting  channels. 

2.1.3  Climate.  The  climate  varies  from  humid,  almost  subtropic  in 
the  east  and  southeast  portion  of  the  division,  to  semiarid  in  the 
western  portion.  The  great  variation  in  topography  from  14,000 
feet  near  the  Continental  Divide,  to  sea  level  along  the  Gulf  Coast 
contribute  to  climatological  variations.  Temperature  extremes  of 
-50  degrees  to  over  120  degrees  have  occurred.  The  normal  daily 
maximum  temperature  for  January  in  the  headwater  areas  of  the  Ar¬ 
kansas  and  Rio  Grande  in  Colorado  is  about  10  degrees  while  average 
daily  minirauras  are  below  zero.  Along  the  Gulf  Coast  in  January  the 
normal  average  dally  maximum  temperature  is  about  70  degrees  with 
minimum  averaging  about  50  degrees.  July  temperature  variation  is 
not  as  pronounced  with  normal  daily  maximum  temperatures  near  80 
degrees  in  the  mountains  to  near  95  degrees  in  the  central  plains 
and  minimum  temperatures  from  40  degrees  to  75  degrees.  Annual  av¬ 
erage  precipitation  also  varies  widely.  Portions  of  the  high 
plains  of  eastern  Colorado  receive  less  than  8  inches  annually 
while  the  hills  of  western  Arkansas  average  over  56  Inches  annual¬ 
ly.  Rainfall  over  the  plains  is  uneven  and  is  often  insufficient 
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purposes.  The  Gulf  Coast  Is  occasionally  subjected  to  tropical 
storms  or  hurricanes  with  rainfall  from  these  storms  extending 
well  into  the  interior  areas.  The  western  portion  of  the  division 
has  average  snowfall  ranging  from  21  inches  across  the  plains  to 
150  inches  in  the  mountains. 

2.2  Water  Control  Projects.  Corps  of  Engineers  involvement  in  water 
resources  development  started  in  SWD  with  the  construction  of  Conchas 
Reservoir  (Albuquerque  District)  which  was  completed  in  1939.  Since 
that  time  the  Corps  has  completed  77  multipurpose  reservoirs  and  12  nav¬ 
igation  locks  and  dams.  Storage  projects  range  in  capacity  from  about 
25,000  acre-feet  to  5.4  million  acre-feet.  There  are  five  additional 
Corps  reservoirs  and  one  section  7  project  under  construction  which  are 
scheduled  to  be  placed  in  operation  by  1983.  The  Corps  is  also  charged 
with  the  regulation  of  the  flood  control  storage  in  13  reservoirs  con¬ 
structed  by  other  agencies  using  Federal  funds  (Section  7  projects).  In 
addition  to  the  reservoirs,  SWD  has  constructed  over  50  local  protection 
projects  including  floodways,  levees,  pump  stations,  hurricane  wave  and 
surge  protection,  the  Intercoastal  Waterway,  and  harbor  and  deep  water 
channel  projects. 

2.3  Water  Control  Management  Responsibilities.  The  water  control  man¬ 
agement  responsibilities  of  the  division  and  district  water  control  man¬ 
agers  have  been  prescribed  in  several  regulations.  These  are  cited  for 
reference  as  follows: 

a.  ER  I0-I-3,  ORGANIZATION  AND  FUNCTIONS ,  Divisions  and  Districts. 

b.  ER  1110-2-1400,  Reservoir  Control  Centers. 

c.  ER  1110-2-240,  Water  Control  Management. 

d.  EM  1110-2-3600,  Reservoir  Regulation. 

e.  SWDR  10-1-1,  Organization  and  Functions,  Southwestern  Division 
Oflice  (SWDO)  and  districts. 

f.  District  regulations  of  functional  statements  (see  the  appro¬ 
priate  district  regulation  10-1-1  or  10-1-3). 

g.  SWD  RCC  Guidance  Memorandum. 

2.3.1  Division  Office  -  Reservoir  Control  Center  (RCC).  The  RCC 
in  the  division  office  is  responsible  (SWDR  10-1-1)  for  the  over¬ 
all  management  of  the  water  control  activities  within  SWD.  This 
requires  collecting  and  analyzing  sufficient  data  on  a  day-to-day 
basis  to  stay  abreast  of  activities  within  the  division  and  be  in 
a  position  to  coordinate  water  control  activities  between  dis¬ 
tricts,  other  divisions  and  agencies. 
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2.3.2  District  Office  Reservoir  Control  Sections.  Within  SWD 
each  of  the  five  districts  have  been  delegated  the  basic  responsi¬ 
bility  for  prescribing  the  water  control  activities  at  projects 
located  within  the  district  boundary,  this  includes  the  collec¬ 
tion,  reporting,  analysis  and  display  of  data  necessary  for  day- 
to-day  water  control  activities.  It  also  requires  the  exchange  of 
water  management  data  with  other  Federal,  State,  and  local  agen¬ 
cies  who  have  an  interest  in  the  use  of  waters  stored  or  released 
from  the  Corps  of  Engineers  projects.  In  districts  where  the 
streams  cross  the  district  boundary,  the  regulation  in  the  adja¬ 
cent  district  has  to  be  coordinated.  The  district  functions  vary 
to  some  degree,  depending  on  the  number  and  type  of  projects  lo¬ 
cated  in  the  district,  geographical  area,  climate  and  other  con¬ 
ditions.  The  requirement  to  support  the  district  and  division 
functions  are  detailed  in  Chapter  V. 


III.  SWD  DATA  COLLECTION  &  ANALYSIS  REQUIREMENTS 


3.1  General.  The  SWD  Water  Control  Managers  require  collection  and 
analysis  of  a  wide  variety  of  real-time  environmental  and  operational 
data  from  about  570  field  sites  throughout  the  division.  These  data 
fall  under  several  categories  which  are  described  in  the  following  para¬ 
graphs  . 


3.1.1  Hydrologic-Hydraulic  Data.  This  category  includes  all  data 
which  indicate  the  status  of  stored  and  flowing  water  at  various 
lakes  and  stream  locations  throughout  SWD.  These  data  are  gener¬ 
ally  the  most  important  in  making  water  control  decisions  and  have 
the  highest  data  collection  priority.  The  frequency  at  which 
these  data  are  required  varies  from  one  report  a  day  to  once  every 
hour,  depending  on  conditions  at  the  site.  Hydrographs  on  the 
small  streams  which  affect  projects  in  the  western  and  southern 
portion  of  SWD  peak  in  4-12  hours.  Types  of  data  included  in  this 
category  are: 

a.  Stream  Stage.  Normally,  a  minimum  of  one  reading  per  day  is 
required.  This  requirement  can  increase  to  several  readings  per 
day  during  storm  runoff  periods. 

b.  Project  Data.  The  following  types  of  data  indicate  project 
conditions  and  are  used  to  determine  rate  of  water  inflow  and  re¬ 
lease.  The  frequency  of  these  reports  depend  on  the  activity  at 
the  project. 

(1)  Headwater  State.  Required  hourly  during  severe  runoff 
events.  Normally  4-  or  8-hour  readings. 

(2)  Tallwater  Stage.  Depends  on  frequency  of  release  changes. 

(3)  Talnter  Gate  Opening.  May  be  as  frequent  as  every  15 
minutes;  3-4  per  day  on  average. 


(4) 

Sluice  Gate  Opening.  Same  as  tainter  gates. 

(5) 

Valve  Opening. 

Same  as  tainter  gates. 

(6) 

Turbine  Flow. 

Depends  on  power  demands. 

SWD 

projects  are 

used 

for  peaking. 

(7) 

Lockage  Volume 

.  Daily. 

Marine  Data  (Galveston  District  Only).  These 

data 

include  tide 

stage  condition  frequency  increases  to  hourly. 

d.  Snow  Data  (Albuquerque  District  Only).  These  data  may  include 
snow  depth,  water  content,  and  temperature.  Requirement  is 
seasonal . 

3.1.2  Meteorologlc  Data.  Meteorological  data  are  used  to  fore¬ 
cast  flows  in  the  stream  above  water  control  structures  (lakes). 
Timely  receipt  of  these  data  can  have  a  significant  effect  on 
real-time  water  control  decisions. 
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One  example  of  the  Importance  of  these  data  is  the  operation  of  Addicks 
and  Barker  projects  located  above  the  city  of  Houston.  The  plan  of 
regulation  calls  for  adjusting  the  outflow  as  soon  as  1  inch  of  rain  is 
reported  downstream.  This  is  a  high  risk  area  with  rapid  runoff  rates 
from  residential  areas  below  the  projects.  Another  example  is  the  B. 

A.  Steinhagen  Lake  where  gate  operations  have  to  be  initiated  within  a 
short  time  frame  to  respond  to  runoff  from  the  local  area  above  the 
project. 


a.  Precipitation.  Daily  or  every  3  hours  during  a  storm  period. 

b.  Evaporation.  Daily. 

c.  Mind  Direction  and  Wind  Speed.  Daily. 

d.  Air  Temperature.  Daily. 

e .  Radar  Maps  or  Reports.  Hour ly . 

3.1.3  Water  Quality  Data.  Water  quality  data  are  collected  at 
those  locations  within  SWD  where  water  quality  could  be  affected 
by  SWD  water  control  operations.  This  data  category  normally  has 
a  lower  data  collection  priority  than  Hydrologic-Hydraulic  or  Me- 
teorologic  data  during  flood  control  or  high  water  volume  opera¬ 
tions,  but  assumes  a  higher  priority  during  low  flow  conditions. 
Water  quality  data  are  collected  as  required  at  both  field  data 
collection  sites  and  by  portable  equipment  located  at  sites  deter¬ 
mined  by  SWD  water  control  personnel.  Types  of  water  quality  data 
most  frequently  collected  are  as  follows: 

a.  Water  Temperature.  Hourly  when  changing  release  rates  to 
assure  that  discharge  is  meeting  target  temperature.  After 
flows  settle  out  frequency  would  reduce  to  about  4  hours. 

b.  Dissolved  Oxygen.  Same  as  water  temperature. 

3.1.4  Other  Data 

a.  Hydroelectric  power.  The  total  daily  power  (megawatts)  gener¬ 
ated  from  each  hydroelectric  installation. 

b.  Piezometer  readings.  These  data  shall  be  monitored  where  re¬ 
quired  . 

3.2  Data  Exchange.  Exchange  of  data  is  required  between  adjoining  dis¬ 
tricts  who  have  a  common  watershed  or  river  basin.  In  order  to  meet  the 
responsibilities  described  in  Chapter  II,  it  is  also  necessary  for  the 
districts  to  exchange  data  with  the  division.  In  addition  to  the  data 
exchange  requirements  within  SWD,  data  are  exchanged  with  the  Chief  of 
Engineers  office  and  the  Lower  Mississippi  Valley  Division  (1MVD). 
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3.2.1 


Other  Federal  Agencies . 


a.  National  Weather  Service.  A  large  volume  of  data  exchange 
takes  place  between  the  Corps  of  Engineers  and  National  Weather 
Service  (NWS).  The  types  of  data  Include  precipitation,  stream 
stages,  lake  evaluations  and  releases,  stream  forecasts,  weath¬ 
er  forecasts,  storm  warnings,  hurricane  forecasts,  etc.  It 
will  be  necessary  for  the  Corps  to  Interface  with  the  NWS  data 
system  for  data  exchange.  The  current  plans  are  for  the  inter¬ 
face  to  be  with  the  S/140  computers  at  the  NWS  River  Forecast 
Centers. 

b.  Southwestern  Power  Administration  (SWPA).  Manages  the  sale 
of  hydroelectric  power  from  the  SWD  hydroprojects. 

c.  Bureau  of  Reclamation.  Corps  of  Engineers  Is  responsible 
for  prescribing  the  oi  ration  of  flood  control  storage  under 
Section  7  of  1944  Flood  Control  Act.  Therefore,  an  exchange  of 
project  data  Is  necessary. 

d.  US  Geographical  Survey  (USGS).  Streamflow  measurements, 
observers,  etc. 

3.2.2  State  and  Local  Agencies.  There  are  several  State  River 
Authorities,  water  districts,  and  municipalities  which  have  proj¬ 
ects  which  affect  the  operation  of  Corps  of  Engineers  projects. 

It  is,  therefore,  necessary  to  maintain  an  exchange  of  data  with 
these  agencies. 

3.3  Data  Processing  and  Analysis.  The  data  processing  and  analysis 
involves  performing  a  number  of  calculations,  conversions,  tabula¬ 
tions,  and  graphical  plottings  to  change  the  raw  field  data  into  a 
form  suitable  for  water  management  decisionmaking.  A  few  examples  of 
data  processing  are  shown  below  with  detailed  descriptions  in  Chapter 
V. 


a.  Converting  stages  to  flow. 

b.  Computing  inflow  to  the  lakes. 

c.  Computing  release  rates  and  volumes. 

d.  Routing  streamflow  and  releases  to  control  points. 

e.  Forecasting  inflow  to  the  l,»,ss. 

f.  Forecasting  runoff  from  rainfall  or  snowmelt. 

g.  Computing  required  releases  from  a  lake  or  system  of 
lakes . 
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h.  Hydropower  generation  allocation  and  actual. 

i.  Computing  system  release  rates. 

j.  Water  temperature  of  releases. 

3.3.1  Reports.  Much  of  the  data  collected,  processed,  and  used 
for  water  control  decisions  end  up  in  the  form  of  reports.  Sever¬ 
al  of  the  reports  used  in  the  districts  and  division  (RCC)  are 
listed  as  follows: 

a.  Daily  Reports. 

(1)  Individual  project  operations  (districts). 

(2)  Benefits  from  operations. 

(3)  Major  water  control  system  summaries. 

(4)  Narrative  on  significant  events  in  district  operation. 

b.  Annual  Reports  (districts,  RCC).  These  reports  are  largely 
narrative  in  form.  Significant  events  are  summarized  in  text, 
graphical  and  tabular  forms. 

3.3.2  Briefing.  Briefing  of  the  following  personnel  on  water 
control  field  conditions  and  operations: 

a.  Water  Control  Managers  (districts,  RCC). 

b.  Emergency  Operations  Personnel  (districts). 

c.  COE  Executives  (districts,  RCC). 

d.  Media  personnel  (districts,  RCC)  through  Public  Affairs  Of¬ 
fice. 

e.  Construction-Operations  personnel  (districts). 

f.  Office  of  Chief  of.  Engineers  (RCC). 
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IV.  SWD  WATER  CONTROL  DATA  SYSTEM 


4.1  General .  The  major  components  of  the  SWD  WCDS  consist  of: 

a.  Remote  gaging  stations  equipped  with  sensors  and  telemetry  de¬ 
vices. 

b.  Communications  equipment. 

c.  Data  acquisition  and  processing  equipment  (ADPE)  located  at 
three  district  offices  (Fort  Worth,  TX;  Little  Rock,  AR;  and 
Tulsa,  OK  and  the  division  office  (Dallas,  TX). 

d.  Display  and  distribution  devices. 

The  ADPE  located  at  each  site  will  have  the  capability  to  exchange 
data  with  another  site  in  the  system  and  software  shall  be  trans¬ 
portable  from  site  to  site.  The  Albuquerque  and  Galveston  Dis¬ 
tricts  will  remote  from  the  Dallas  computer. 

4.2  Field  Data  Collection.  The  WCDS  Master  Plan  provides  for  the 
primary  method  of  field  data  collection  to  be  via  the  Geostationary 
Orbiting  Environmental  Satellite  (GOES)  system.  The  system  will  also 
contain  stations  which  collect  and  transmit  data  via  telephone  and 
llne-of-site  radio.  The  present  plan  includes  350-450  stations  which 
will  be  equipped  to  automatically  telemeter  data  to  the  district  and/ 
or  division  processors.  There  will  also  be  a  portion  of  the  data 
(primarily  from  the  project  offices)  which  will  be  entered  into  the 
system  via  a  microprocessor  such  as  an  Apple,  or  via  a  TTY  terminal. 

A  portion  of  the  field  data  will  be  obtained  through  data  exchange  ar¬ 
rangements  with  other  agencies.  This  will  be  accomplished  via  TTY 
type  terminals  and  computer  to  computer  communications.  The  frequency 
of  data  transmission  wi 1 L  vary  with  the  importance  of  the  site.  How¬ 
ever,  in  general,  the  transmission  frequency  will  range  from  1  to  4 
hours . 


4.2.1  Type  of  Data  Col lected .  The  majority  of  the  stations  will 
be  reporting  one  to  two  types  of  environmental  data  plus  station 
equipment  health  data.  There  will  be  several  types  of  data  re¬ 
ported  from  the  project  sites.  The  data  will  include  the  follow¬ 
ing  list  of  parameters  although  stream  stage  and  precipitation 
will  be  the  most  prominent  type. 

a.  Stream  Stage 

b.  Precipitation 

c.  battery  Voltage 

d.  Lake  Level 

e.  Evaporation 

f.  Water  temperature 
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g.  Air  temperature  (max,  min,  current) 

h.  Wind  speed 

1.  Wind  direction 

j.  Hydropower  generation 

k.  Water  withdrawal  through  metered  lines 

l.  Gate  openings  &  corresponding  times 

m.  Snow  depths 

n.  Snow  water  equivalents 

4.2.2  Manual  and  Semi -Automated  Methods.  This  will  involve  en¬ 
tering  visual  observations  into  the  system  by  use  of  a  TTY  termin¬ 
al  or  microprocessor.  It  is  planned  that  these  data  could  be  en¬ 
tered  into  the  system  by  the  terminal  operator  or  as  an  option 
stored  on  the  terminal  or  microprocesser  for  retrieval  upon  inter¬ 
rogation  by  the  district  or  division  computer.  This  could  be  ac¬ 
complished  by  the  auto-calling  capability  of  these  computers. 

4.2.3  Automated  Methods. 

a.  Telephone.  There  are  over  100  gages  which  are  currently 
equipped  with  a  DARDC  which  transmits  information  on  interroga¬ 
tion  via  telephone.  The  output  from  the  DARDC  is  standard 
asynchronous  ASCII  Code.  These  devices  will  be  interrogated  by 
the  computer  using  an  auto-calling  unit. 

b.  Radio.  The  Little  Rock  District  has  a  network  of  radio 
stations.  This  network  is  controlled  by  a  NOVA  1200  minicompu¬ 
ter.  This  network  currently  outputs  data  to  an  ASR  33  tele¬ 
type. 

c.  GOES .  The  remainder  of  the  stations  will  be  equipped  with 
Data  Collection  Platform  Radio  Sets  (DCPRS)  which  will  transmit 
over  the  GOES  system.  Currently  there  are  three  types  of  DCPRS 
in  the  network.  These  are  (1)  LaBarage  self-timed,  (2)  Handar 
2-channel  (one  channel  self-timed  and  one  channel  emergency 
threshold)  and  (3)  Sutron  adaptive  random  which  transmits  in 
both  the  self-timed  and  adaptive  random  mode.  It  is  important 
to  note  that  each  of  these  platforms  have  a  different  data  for¬ 
mat.  The  data  from  the  DCPRS  wi L  l  be  retrieved  through  the 
GOES  Data  Collection  System  (DCS)  located  in  the  World  Weather 
Building,  Camp  Springs,  Maryland.  The  data  will  be  transferred 
from  the  DCS  at  Camp  Springs  to  the  WCDS  computers  via  dial-up 
telephone  line.  This  is  expected  to  be  accomplished  automatic¬ 
ally,  computer  to  computer,  by  use  of  the  auto-calling  capabil¬ 
ity  of  the  WCDS  computers.  Transmission  rates  are  to  be  at 
4800  BAUD.  A  Corps  wide  study  is  currently  being  conducted  to 
determine  the  feasibility  of  a  network  of  Corps  ground  receive 
sites  for  the  GOES.  Depending  on  the  results  of  this  9tudy  the 
future  retrieval  of  DCPRS  transmissions  may  be  through  a  Corps 
ground  receive  site. 


4 . 3  System  Hardware 


4.3.1  Computer  Configuration.  The  minicomputers  used  in  the  system 
are  Harris.  Each  of  the  three  district  offices  have  a  configuration 
consisting  of  a  H-LOO  and  H-500  minicomputer.  The  H-100  serves  as  the 
primary  communication  and  data  logging  processor.  The  H-500  serves  as 
the  primary  processing  unit  with  the  capability  of  assuming  the  com¬ 
munication  and  logging  function  in  the  event  of  failure  of  the  H-100. 
The  district  systems  and  division  machine  are  expected  to  operate  as  a 
network  which  wiLl  provide  for  data  exchange  and  back-up  capability.  A 
brief  summary  of  the  equipment  at  each  site  is  presented  in  Table  4-1. 


TABLE  4-1 

COMPUTER  HARDWARE  LIST 


SITE 

ITEM  DESCRIPTION 

I  — F0KT 
WORTH 

LITTLE 

ROCK. 

TULSA 

DALLAS 

Harris  500  Computer  with  error 

1 

1 

1 

1 

correcting  MOS  memory  &  virtual 
memory 

Scientific  Arithmetic  Unit  (SAU) 

1 

1 

1 

1 

Line  Printer,  300  LPM 

2 

1 

1 

1 

Disc  Drive,  HUM  BYTE 

1 

1 

- 

1 

Disc  Drive,  3COM  BYTE 

I 

i 

2 

1 

Magnetic  Tape  Unit,  9  track, 
800/1600  BPI,  45  IPS  (switch- 

1 

} 

1 

1 

1 

able  to  H-100) 

Direct  Memory  Access  Communica¬ 

2 

1 

2 

2 

tions  Processor  (DMACP-16) 

Harris  100  Computer  with  error 

1 

1 

l 

1 

_ 

correcting  MOS  memory  6  virtual 
memory 

Disc  Drive,  8(IM  BYTE 

i 

1 

1 

DMACP-16 

1 

! 

1 

- 

VADIC  Auto-Call  Unit 

1 

1 

l 

1 

4.3.2  Display  Equipment.  The  amount  of  display  equipment  at  each 
site  varies  with  the  site  work  load.  Generally,  the  types  of 
equipment  at  each  site  will  be  (1)  B/W  CRT's  (80  col.  24  line 
screens),  (2)  Color  Graphic  CRT's,  (3)  hard  copy  terminals,  (4) 
graphic  tablets,  (5)  flat  bed  graphic  plotters,  and  (6)  future 
large  screen  display.  The  color  graphic  CRT's  are  expected  to  be 
Tektronix  compatible. 


4.3.3  Emergency  Message  Equipment.  As  the  system  becomes  fully 
functional,  voice  synthesizers  will  be  added  in  connection  with  the 
auto-call  to  provide  messages  for  tl. »  duty  person. 

4.4  Operating  System  Software.  The  Harris  operating  system  software 
being  used  on  the  computers  is  '"VOS."  The  other  system  software  pack¬ 
ages  available  on  the  system  computers  are: 


a.  SORT/MERGE 

b.  FORTRAN  77 

c.  TOTAL  II  Data  Base  Management  System 

d.  AZ7  QUERY  LANGUAGE  with  Report  Writer 

e.  AZ7 /TOTAL  INTERFACE 

f.  Remote  Job  Entry  to  CUC  200UT  EMULATION 

g.  Remote  Job  Entry  to  IBM  2780  EMULATION 

h.  Remote  Job  Entry  IBM  2780  Host 


Remote  Job  Entry  to  IBM  HASP  II  M/L  WORK  STATION  EMULATION 
Remote  Job  Entry  to  IBM  HASP  II  M/L  WORK  STATION  HOST 


k.  VADIC  AUTO  DIAL  Software 


V.  WCDS  USER  REQUIREMENTS 


5 . 1  General. 

This  chapter  details  user  requirements  for  the  system  and  is  not  in¬ 
tended  to  be  a  Listing  of  software  necessary  to  produce  these  products. 
Chapter  VI,  "Software  Development  to  Support  User  Requirements,"  pre¬ 
sents  the  individual  software  Items/programs  to  produce  the  user  product 
requirements  shown  in  this  chapter.  In  order  to  simplify  discussions  of 
user  requirements  this  chapter  is  divided  into  four  major  divisions: 

5.2  An  Overview  of  User  Requirements;  5.3  Water  Control  Products;  5.4 
Support  Requirements;  and  5.5  Special  Requirements. 

The  SWD  Water  Control  Data  System  (WCDS)  will  be  a  "user  friendly"  sys¬ 
tem  allowing  persons  of  various  technical  backgrounds  (hydrologic,  hy¬ 
draulic,  water  control  and  ADP)  to  access  the  system  and  produce  a 
multitude  of  products.  The  system  will  be  structured  so  that  the  com¬ 
plexity  of  individual  software  items  is  imperceptible  to  most  users. 

Many  of  the  data  display  products  will  be  nenu  driven,  guiding  the  user 
through  the  display  system  to  the  specific  product  desired.  Others  may 
be  accessed  as  a  "real-time"  program,  active  on  specific  terminals  at 
any  time.  Some  products  will  require  extensive  user  intervention  and  a 
working  knowledge  of  the  specific  task  being  undertaken  and  of  the  soft¬ 
ware  being  used. 

5.2  An  Overview  of  User  Requirements.  Water  management  activities 
require  acquisition,  display,  interpretation,  and  transmission  of  sig¬ 
nificant  volumes  of  hydro-meterologic  and  project  data  daily.  Most 
Water  Management  units  are  staffed  to  handle  this  data  during  typical 
low  flow  situations,  producing  daily  reports  of  project  operation  (re¬ 
servoir  regulation)  activities  and  general  hydrologic  conditions  in  a 
real-time  manner.  Flood  periods  stress  most  units  to  the  utmost.  Data 
volumes  increase  significantly  requiring  additional  time  to  transfer 
data  from  projects,  stream  gages  and  rainfall  stations.  The  number  of 
computations  required  for  forecasts  and  displays  increases  significantly 
although  hydrologic  computations  have  been  simplified  to  some  extent  by 
the  development  of  computer  and  graphical  methods  for  flow  hydrograph 
computation  and  flood  routing. 

One  of  the  more  useful  products  to  meet  user  requirements  is  the  display 
of  raw  and  computed  basic  data.  Once  the  data  are  in  the  system,  tabu¬ 
lar  displays  of  single  and  multiple  parameters  for  a  specified  gaging 
station  or  project  will  probably  be  used  more  than  any  other  product. 
Tabular  and/or  graphic  displays  for  time  series  data  that  display  his¬ 
toric,  current,  and  forecasted  data  on  a  real-time  basis  are  required. 
This  product  will  display  any  data  in  the  data  base  including  the  latest 
forecast.  Forecasted  data  will  begin  at  the  time  of  the  forecast,  over¬ 
lapping  the  latest  recorded  data,  if  necessary. 
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Data  analysis  and  forecasting  modules  (software)  will  be  constructed  so 
that  the  forecaster  can  add,  delete,  or  correct  data  at  several  points 
in  the  forecasting  process.  Watershed  rainfall  displays  by  6-hour,  12- 
hour,  or  24-hour  periods  will  show  individual  stations  and  computed  ba¬ 
sin  totals.  Description  of  both  tabular  and  graphical  displays  are 
included  in  Section  5.3. 

The  software  should  be  structured  to  allow  specified  users  intervention 
at  several  previously  determined  points  in  the  forecasting  and  other 
analysis  group  modules. 

Products  described  in  paragraphs  5.3,  5.4  and  5.5  are  those  required 
for  Water  Control  and  are  not  necessarily  related  to  present  require¬ 
ments.  Numerous  functions  that  presently  require  tabulating  and  dis¬ 
playing  data  in  order  to  screen  data,  perform  computations,  make 
forecasts,  and  produce  tabular  reports  will  be  performed  automatically 
or  with  minor  user  intervention.  User  requirements  reflect  these 
changes  by  dealing  more  with  display  and  edit  products  and  the  analysis 
group  software  rather  than  dwelling  on  data  acquisition  and  database 
design  and  management. 

5.3  Water  Control  Products.  These  products  reflect  the  basic  needs  of 
water  management  personnel  in  performing  their  assigned  functions.  The 
products  are  organized  to  some  extent  by  function  beginning  with  tabu¬ 
lar  displays  of  single  data  elements  and  expanding  to  the  fixed  format 
reports  disseminated  periodically  to  other  users  and  of  the  graphical 
displays.  Data  Acquisition  Group,  Data  Base  and  Analysis  Group  pro¬ 
grams  used  will  be  Imperceptible  to  most  users.  They  will  use  Data 
Base  Utilities  group  software  items,  primarily  the  display  and  graphi¬ 
cal  edit  unit  to  produce  required  products.  The  remainder  of  this 
section  contains  descriptions  of  specific  products  to  meet  user  re¬ 
quirements  . 

5.3.1  Data  Displays.  This  is  a  basic  user  requirement:  Display 
of  any  data  element  available  in  the  data  base  including  pertinent 
data,  rating  curves/tables ,  storage  vs.  elevation  data  and  basic 
data  should  be  easily  accessible  by  ail  users.  Menu  driven  dis¬ 
plays  would  aid  casual  users  leading  them  through  a  series  of  menus 
to  the  data  needed.  More  knowledgeable  users  will  be  able  to  go 
directly  to  the  product  desired.  Examples  of  these  displays  are 
shown  on  figures  5-1  and  5-2. 

All  time  sequence  displays  will  be  on  an  hourly  basis  where  the  pa¬ 
rameters  are  available  hourly  or  more  often.  Observed  data  will  be 
maintained  a  limited  time;  therefore,  displays  going  back  prior  to 
the  archiving  period  will  be  displayed  on  whatever  basis  is  availa¬ 
ble,  Displays  of  forecasts  will  be  In  6-,  1 2— ,  or  24-hour  periods 
depending  on  the  time  increment  used  in  the  forecast.  Displays  of 
short-term  data  will  be  displayed  in  hourly  increments  unless  the 
all  parameter  is  specified,  then  every  reading  is  displayed. 

Data  displayed  by  any  of  these  displays  may  be  changed  by  certain 
users.  Access  to  the  data  changing  mode  will  be  restricted  to 
specified  users  and/or  terminals  by  access  codes. 
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Any  parameter  read  In,  converted,  or  computed,  can  be  output  using 
Che  "Display"  program.  Station  names(s),  parameter(s) ,  time  peri¬ 
od  and  time  increment  are  input. 

The  software  sets  up  the  format  in  the  order  specified  by  the 
user.  If  the  data  are  not  available  in  the  specified  time  incre¬ 
ment,  the  program  will  select  the  next  longer  increment  available 
for  output. 


5.3.1. 1  Single  Parameter  -  Single  Site.  Display  of  the  last 
available  reading  of  a  single  parameter  from  one  specified  site 
(figure  5-3).  Any  single  data  point  along  with  the  date  and 
time  of  reading  can  be  displayed  on  the  console.  Access  should 
be  by  entering  station  name  and  parameter. 

5.3. 1.2  Multiple  Parameters  -  Single  Site.  Multiple  parame¬ 
ters  may  be  displayed  using  a  similar  input  format  (figure 
5-3).  Output  will  be  the  latest  verified  readings  or  computed 
values.  Access  will  be  by  entering  the  station  name  followed 
by  the  parameters.  Output  format  will  include  date/time,  proj¬ 
ect  name,  and  parameters. 

5.3. 1.3  Single  Parameter  -  Single  Site  -  Time  Series.  Most 
single  parameter  displays  need  a  reference  to  previous  readings 
or  to  a  definite  reference  point,  to  be  fully  useful.  It  Is 
essential,  therefore,  to  be  able  to  display  time  sequences  of 
individual  parameters.  Access  to  time  sequence  data  should  be 
as  easy  as  to  the  previous  products.  From  a  terminal  the  user 
will  enter  the  station  name,  parameter(s)  and  the  length  of  a 
time  desired.  Data  are  displayed  on  an  hourly  basis  beginning 
”T"  hours  before  the  last  hourly  data  point  in  the  file.  Exam¬ 
ples  of  input  and  output  are  shown  on  Figure  5-4. 

5.3. 1.4  Multiple  Parameter-Single  Site-Time  Series.  Time  se¬ 
quence  multipararaeter  displays  are  useful  tools  to  determine 
current  conditions  at  a  project.  Displays  of  lake  elevation, 
inflow,  outflow,  rainfall  and  other  parameters  aid  users  when 
making  real  time  water  management  decisions.  By  looking  at  a 
time  sequence  display  of  inflow,  for  example,  a  user  can  tell 
where  a  runoff  hydrograph  is  in  relation  to  peak.  Other  useful 
tools  for  real  time  water  control  are  pool  elevation  and  rain- 
falL.  This  product  is  available  by  entering  the  project  name, 
parameters  and  time  in  hours.  An  example  is  shown  on  Figure 
5-5. 


5.3. 1.5  Multiple  Parameter  -  Multiple  Site  -  Time  Series.  Al¬ 
low  the  user  to  look  at  more  than  one  project's  data  simultane¬ 
ously.  Parameters  will  be  displayed  in  the  time  sequence 
specified  by  the  user.  Parameters  not  available  will  be  omit¬ 
ted.  The  Arkansas  River  Locks  and  Dams  and  run  of  river  hydro- 
power  projects  with  hour  to  hour  flow  changes  are  conclusive  to 
this  type  display.  An  example  is  shown  on  Figure  5-6. 
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5. 3. 1.6  Multiple  Parameter  -  Watershed  -  Time  Series.  Time  ser¬ 
ies  data  displays  for  single  or  multiple  parameters  over  a  water¬ 
shed  or  basin  include  incremental  rainfall  for  all  stations  in  a 
basin  with  weighted  basin  rainfall,  flows  for  major  flow  stations 
including  intervening  area  flows  and  routed  project  releases.  An 
example  is  shown  on  Figure  3-7. 

5.3.2  Graphics  Displays.  Graphics  displays  of  point,  and  averaged 
(computed)  data,  both  historical  and  forecasted,  are  a  necessity  to 
water  managers  both  from  a  working  standpoint  and  ir.  briefings.  Ba¬ 
sically  five  types  of  displays  are  included  in  this  discussion.  Each 
must  be  capable  of  expansion  to  some  extent.  All  of  the  CRT  graphics 
will  have  the  capability  for  the  user  to  change  any  data  item  or  graph 
displayed,  interactively,  with  graphics  pen  and  on  the  CRT.  The  user 
can,  at  his  discretion,  update  the  data  base  with  the  corrected 
(changed)  data. 

5.3.2. I  Data  Point  Plots  -  Data  point  plots  are  time  series 
graphical  representation  of  any  single  data  teem  (Figure  5-8). 
Items  such  as  instantaneous  readings  of  pool  elevation,  tailwater 
elevation,  stage,  flow,  individual  outlet  release,  total  release, 
reservoir  storage  temperature,  dissolved  oxygen,  conductivity,  pH, 
and  generation  can  be  plotted  as  single  point  on  a  time  series 
plot.  The  list  is  not  complete  but  will  expand  as  the  data  base 
expands.  Points  may  or  may  not  be  connected  as  the  user  speci¬ 
fies. 


5. 3. 2. 2  Average  Data  Plots.  Average  data  plots  are  time  series 
graphical  presentation  of  averaged  data  such  as  reservoir  inflow 
or  generator  (MWH).  Displays  of  this  type  (Figure  5-9)  will  use  a 
connected  unfilled  bar-graph  type  plot  of  the  average  value  during 
the  time  period.  The  system  will  have  the  capability  to  call  the 
graphical  displays  using  basically  the  same  commands  used  for  the 
previous  tabular  displays. 

5. 3. 2. 3  Hydrograph  Plots.  Hydrograph  plots  (Figure  5-10)  are  ne¬ 
cessary  to  present  flow  hydrographs  as  smooth  lines.  The  data  are 
the  computed  average  over  varying  time  periods.  This  plot  will 
utilize  area  balancing  and  flow  peak  computing  algorithms  to  pro¬ 
duce  a  smooth  line  display.  Scales  will  be  developed  by  the  soft¬ 
ware  but  may  be  altered  by  the  user  at  his  discretion. 

5. 3. 2.4  Map  Plots  1 .  These  plots  will  use  base  maps  with  over¬ 
lays  of  point  water  control  information  such  as  precipitation, 
river  stages,  discharges,  flooded  areas,  snow  depth  and  water 
equivalence,  API's  etc.  These  are  to  be  overlaid  over  user  se¬ 
lectable  base  maps  such  as  regional  maps  showing  user  selectable 
features  such  as  major  rivers  and  tributaries,  major  cities  and 
highways,  primary  river  gages;  division  maps  showing  lake  proj¬ 
ects,  district  boundaries,  division  and  district  office  symbols; 
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district  area  maps  with  major  river  basins,  rivers  and  tribu¬ 
taries,  significant  cities,  major  river  gages,  lake  and  levee 
projects,  major  highways;  State  maps;  river  basin  maps;  water¬ 
shed  maps  upstream  and  downstream  of  each  lake  project  with 
pertinent  details  such  as  tributaries  and  subbasins,  key  rain¬ 
fall  and  river  stations,  levees,  etc.  Display  capability  will 
Include  at  least  five  data  points  for  each  station  using  dif¬ 
ferent  colors  for  each  set  of  data  points  and  flashing  capabil¬ 
ity  when  a  value  exceeds  a  threshold  such  as  "fWS  Flood  Stage," 
"operating  stage,"  "critical"  stage,  API,  etc.  See  Figure 
5-11, 


5. 3. 2. 5  Map  Plots  2.  These  displays  will  use  the  same  base 
maps  and  data  as  Map  Plots  1  but  will  have  the  additional  capa¬ 
bilities  to  (a)  plot  isohyets  and  computed  average  basin/water¬ 
shed  rainfall  from  the  isohyets  and  (b)  plot  snow  depth  and 
water  equivalent  Isohyets.  Snow  water  content  isohyets  over- 
layed  on  contour  maps  with  the  runoff  potential,  in  inches, 
computed  for  various  contour  intervals  is  used  to  determine 
spring  snowmelt  runoff  by  Albuquerque  District.  This  product 
will  compute  potential  runoff  volumes  from  various  elevations 
with  summations  on  a  watershed-basin  basis.  See  Figure  5-12. 

5.3.3  Data  Analysis  and  Forecasts.  User  requirements  in  this 
area  will  vary  slightly  from  district  to  district.  Most  data 
analyses  and  forecasts  are  now  done  once  a  day  using  manual 
methods.  Therefore,  most  of  the  forecasting  tools,  methods,  and 
procedures  have  been  developed  for  the  analysis  of  data  and  fore¬ 
casting  in  24-hour  increments.  This  Water  Control  Data  System 
will  increase  the  water  management  users'  capability  to  make  fore¬ 
cast  by  significantly  reducing  computation  time  and  providing  per¬ 
iodic  data  updates  unobtainable  by  previous  methods.  User 
requirements  in  the  forecasting  area  are  based  on  anticipated 
water  management  users'  needs  rather  than  on  present  practice. 

All  of  these  products  will  be  written  to  accommodate  6-,  12-,  or 
24-hour  forecast  periods  anticipating  development  of  forecasting 
tools  for  shorter  periods  especially  on  smaller  watersheds. 

5.3. 3.1  Basin-Watershed  Rainfall-Runoff  and  API's.  Basin 
rainfall  is  displayed  in  the  same  format  as  described  in  para¬ 
graph  5.3. 1.6  and  shown  on  Figure  5-7,  listing  individual  sta¬ 
tion  rainfall  amounts  and  the  computed  watershed  weighted 
rainfall.  Rainfall  will  be  displayed  in  periods  compatible 
with  the  forecasting  module  for  the  particular  basin  (6-,  12-, 
or  24-hour)  unless  otherwise  specified.  Individual  rainfall 
values  displayed  can  be  changed  in  this  module  and  the  weighted 
rainfall  recomputed.  Once  the  stat lon/basin  rainfall  is  veri¬ 
fied  by  the  user,  the  station  data  are  updated  in  the  data  base 
and  the  watershed  API  is  updated.  API's  for  the  past  48  hours 
are  then  displayed,  by  forecast  periods,  along  with  watershed/ 
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subwatershed  rainfall  and  runoff  In  inches.  (See  Figure  5-13.) 
The  API's  and  runoff  when  verified  by  the  user  are  stored  for 
further  use.  Precipitation  indicies  will  be  computed  every  6 
hours  (MN,  6A,  Noon,  6P)  based  on  available  data.  A  separate 
display  or  printout  every  6  hours  will  list  those  stations 
where  experienced  rainfall  values  indicate  possible  runoff. 

5. 3. 3. 2  Streamflow  Forecasts.  Streamflow  forecasters  utilize 
tools  which  apply  computed  runoff  (in  inches)  added  to  the  pre¬ 
vious  forecasted  flows  and  base  flows  to  develop  the  full  flow 
routing  and  combining  of  hydrographs  from  upstream  stations 
and/or  project  releases.  The  water  management  user  needs  the 
capability  to  display  each  area  or  subarea  hydrograph  (prefera¬ 
bly  graphic)  either  as  a  single  total  hydrograph  or  segmented 
hydrograph  showing  routed  upstream  hydrographs;  intervening 
area  flow  hydrographs  and  base  flow  hydrographs  at  the  site. 
Hydrographs  are  computed  by  application  of  runoff  (in  inches), 
as  computed  in  paragraph  5. 3. 3.1  above,  to  unit  hydrographs  for 
the  area.  Display  for  a  single  station  is  shown  on  Figure 
5-13.  Flow  forecasts  at  any  point  may  be  altered  by  the  user 
based  on  previous  experience.  Station  forecasts,  when  verified 
by  the  user,  will  be  stored  for  output  by  other  users. 

5.3. 3.3  Reservoir  Inflow  and  Operational  Forecasts.  Reservoir 
inflows  are  forecasted  using  the  method  described  in  paragraph 
5. 3. 3. 2  above.  These  forecasts  should  be  available  for  a  sin¬ 
gle  reservoir  or  a  system  or  reservoirs.  For  reservoir  fore¬ 
casts  the  user  requirements  include  display  of  experienced  and 
forecasted  project  inflows,  control  polnt(s)  flows,  both  with 
and  without  reservoir  releases,  periodic  reservoir  releases  and 
pool  elevations  (Figure  5-15).  Initial  forecasts  will  be  made 
using  the  approved  water  control  plan  for  the  project.  This 
forecast  will  be  stored  for  future  reference.  The  user  may  al¬ 
ter  and  rerun  the  forecast  by  changing  the  operating  stage/ 
stages,  specifying  reservoir  release  schedules,  or  changing  the 
reservoir  inflow  hydrograph  and/or  control  point  intervening 
area  hydrograph,  both  time  and  volume.  Flow  hydrographs,  pool 
elevation  and  release  schedules,  when  verified  by  the  operator, 
will  be  stored  for  use  in  forecasting  at  downstream  points  and 
displays  for  briefings. 

5. 3. 3.4  Long-Range  River  Forecasts.  Long-range  flow  forecasts 
are  required  in  certain  situations  for  maintanence,  navigation, 
low  flow,  and  flood  operations  particularly  on  the  larger  riv¬ 
ers.  These  forecasts  for  specific  stations  shall  allow  user 
intervention  for  the  selection  of  the  desired  flow  conditions. 
These  flow  conditions  will  be  based  on  historical  statistics. 
The  user  shall  be  able  to  select  flows  based  on  these  statis¬ 
tics  such  as  median,  xx  percentile,  frequency,  or  a  percent  of 
median  flows.  The  capability  to  analyze  the  flows  for  the  past 
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30,  60  or  90  days  to  determine  their  relationship  to  the  histor¬ 
ical  statistics  is  desired.  This  will  be  used  to  select  fore¬ 
cast  flow  conditions.  Forecasts  would  begin  with  current  date 
or  at  a  user  selected  point  on  the  current  short-range  fore¬ 
casted  flows. 

5. 3. 3. 5  Long-Range  Reservoir  Forecasts.  This  product  produces 
trend  forecasts  of  lake  levels  based  on  user  selectable  flow 
conditions  described  in  paragraph  5. 3. 3. 4  above.  Forecasts 
would  be  for  a  stated  time  period  or  until  the  lake  reaches  a 
specified  level.  The  user  can  project  reservoir  emptying  times 
based  on  a  variety  of  Inflow  patterns  (both  to  the  lake  and  maj¬ 
or  control  points)  and  regulating  stage  criteria.  Output  would 
be  lake  levels,  release  patterns,  and  flows  and  stages  at  down¬ 
stream  control  points. 

3. 3. 3.6  Hydropower  Allocation  Report.  A  tabular  report  of 
projected  hydropower  operations  for  the  next  month  at  all  SWD 
hydropower  projects  (Figure  5-16).  Inflow  forecasts  based  on 
percent  of  median  flows  for  the  previous  30  days  and  first  of 
current  month  to  date  and  hydropower  operations  are  used  to 
project  the  beginning  of  the  next  month  pool  elevations.  In¬ 
flows  for  the  next  month  are  estimated  by  applying  the  percent 
of  median  flow  computed  for  the  previous  30  days  to  the  median 
inflow  for  the  month  being  computed  (up  to  100  percent).  Maxi¬ 
mum,  minimum  and  recommended  hydropower  generation  allocations 
are  computed.  The  maximum  allocation  is  based  on  the  allowable 
pool  level  drawdown  for  each  project.  The  minimum  allocation 
considers  only  releases  required  for  water  quality  and  fisheries 
operations.  The  recommended  allocation  is  based  on:  (a)  gener¬ 
ating  to  meet  system  or  plant  loads  while  balancing  the  pools 
and  meeting  minimum  releases  and  (b)  firm  energy  output  from 
each  reservoir  or  system  of  reservoirs.  The  time  period  should 
be  user  specified  from  1  week  to  1  year  with  output  weekly  or 
monthly  for  extended  periods. 

5. 3. 3. 7  Navigation  Taper.  This  product  is  similar  to  long- 
range  trend  forecasts  but  operates  the  Arkansas  River  Basin 
projects  for  a  specified  flow  pattern  at  the  Van  Buren,  Arkan¬ 
sas,  gage.  Figure  5-17  shows  the  Van  Buren  Guide  Curve  for 
flood  control  operations.  The  regulated  Van  Buren  flow  is  based 
on  the  equivalent  percent  of  flood  control  storage  used  in  the 
major  flood  control  projects  in  the  basin  and  the  time  of  the 
year.  Project  and  intervening  area  inflows  are  projected  using 
a  percent  of  median  fLow  which  is  user  selectable  (default  value 
would  be  100  percent).  Output  displays  will  show  each  project's 
daily  inflow,  outflow  and  pool  elevation,  the  equivalent  percent 
of  storage  used,  target  flow  at  Van  Buren  and  forecasted  flow  at 
Van  Buren.  Reservoir  release  patterns  for  any  project(s)  may  be 
set  for  the  entire  period  or  any  portion  of  the  forecast  period. 
Algorithms  used  in  this  product  should  be  applicable  to  most 
multireservoir  systems  operated  for  a  single  control  point  by 
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using  data  sets  for  the  specific  basin.  The  display  should 
be  available  in  tabular  or  color  graphical  form.  The  Van 
Buren  hydrograph  should  be  displayable  showing  each  indi¬ 
vidual  project  contribution  to  the  total  hydrograph.  The 
user  should  have  the  capability  to  modify  the  Van  Buren  hy¬ 
drograph  via  use  of  a  graphics  tablet  and  then  recompute 
the  individual  project  release  requirements. 

5. 3. 3.8  Long-Range  Forecasts  -  Reservoir  Systems.  This 
product  is  similar  to  the  long-range  forecasts  for  both 
rivers  and  lakes  and  the  "Navigation  Taper"  product  de¬ 
scribed  above.  The  user  selects  flow  patterns  or  flow  ra¬ 
tios  for  the  entire  basin  or  specific  areas  within  a  basin. 
Initial  output  shows  project  regulation  and  control  point 
flows  and  stages  using  the  approved  water  control  plan. 

The  user  may  alter  inflow  volumes,  reservoir  release  pat¬ 
terns,  and  control  point  criteria  for  additional  runs. 
Forecasts  are  from  the  current  date  until  all  projects  are 
emptied.  Output  shows  individual  project  inflow,  release 
and  pool  elevations,  control  point  flows  and  stages. 

5.3.4  Reports.  Reports  are  periodically  recurring  products  gen¬ 
erally  using  fixed  formats.  The  more  common  products  in  this  area 
are  the  daily  and  monthly  lake  reports.  Some  of  the  products  may 
have  several  formats  for  the  user  to  choose  from.  Products  are 
broken  down  into  three  areas:  (1)  regularly  recurring  reports, 

(2)  as  required  reports  and  (3)  user  selectable  format  reports. 

5. 3. 4.1  Regularly  Recurring  Reports.  These  reports  are 
generally  fixed  format  reports  required  on  a  periodic  ba¬ 
sis.  Most  utilize  a  mixture  of  point  and  daily  average 
data  derived  directly  from  the  data  base.  These  reports 
will  be  initiated  at  predetermined  times  by  the  Master  Con¬ 
troller  but  executed  only  when  all  data  are  available.  The 
reports  may  be  initiated  manually  when  necessary. 

5.3.4. 1.1  Morning  Lake  (Project)  Report.  Tabular 
summary  report  of  current  status  of  all  lakes  in¬ 
cluding:  midnight  and  7:00  a.m.  (or  8:00  a.m.) 
lake  stages;  24-hour  change  in  stage  a.m.  to  a.m., 
storage  used  in  feet  above  or  below  top  of  conser¬ 
vation  pool  and  percent  conservation  or  flood 
storage  used;  total  inflow,  total  releases,  hydro- 
power  releases,  water  supply  releases,  water  sup¬ 
ply  purapage  and/or  diversion,  leakage,  ran.  to  mn. 
and  current  a.m.  release  rate;  and  24-hour  project 
rainfall.  Each  user  office  will  have  a  standard 
format  and  may  have  several  alternate  formats  dis¬ 
playing  other  parameters.  Figures  5-18  through 
5-20  are  examples  of  the  morning  lake  report. 
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5.3.4. 1.2  Morning  River  Report.  Tabular  report 
of  stages,  discharges,  rainfall,  water  tempera¬ 
ture,  other  water  quality  parameters  and  24-hour 
change  in  stage.  Time  and  format  for  report  shall 
be  user  selectable  based  on  user  needs.  Stations 
above  "flood  stage"  or  other  designated  stages  are 
flagged.  Those  exceeding  other  parameter  checks 
are  also  flagged  or  tabulated  separately.  Report 
formats  will  vary  from  office  to  office.  An  exam¬ 
ple  is  shown  on  Figure  5-21. 

5. 3. 4. 1.3  Dally  Generation  Report.  Tabular  re¬ 
port  of  daily  hydropower  generation  at  all  power 
projects.  Report  includes  week  to  date  (beginning 
on  Mondays)  and  month  to  date  figures,  weekly  and 
monthly  allocations,  carryover  (accumulation  of 
energy  greater  than  or  less  than  "firm")  since  the 
pool  went  below  the  rule  curve  (returns  to  zero 
when  the  rule  curve  is  exceeded),  pool  elevation 
(a.ra.)  and  maximum  allowable  drawdown.  Also  in¬ 
cludes  notes  on  the  operation  from  each  user. 
'Writes  to  weekly  and  monthly  files.  An  example  is 
shown  on  Figure  5-22. 

5.3.4. 1.4  Monthly  Lake  Report.  Tabular  or  graph¬ 
ic  summary  of  daily  project  operations  to  include: 
midnight  and  a.ra.  pool  elevations,  midnight  pool 
storage,  24-hour  release  (midnight  to  midnight) 
both  total  and  power,  water  supply  pumpage  or  ir¬ 
rigation  diversion,  evaporation,  adjusted  inflow, 
24-hour  project  and  basin  weighted  rainfall  (a.ra. 
to  a.ra.).  Report  will  include  monthly  totals, 
maximum,  minimum,  and  mean  values  for  each  parame¬ 
ter  as  well  as  a  statement  of  total  water  supply 
withdrawn,  leakage  and  other  losses  as  needed  to 
balance  the  monthly  water  budget  and  the  total  en¬ 
ergy  produced.  Examples  are  shown  on  Figures  5-23 
and  5-24. 


5.3.4. 1.5  Monthly  River  Report.  Tabular  listing 
of  all  stations  7:00  a.ra.  gsge  readings  for  each 
day  of  the  month  with  maximum  and  minimum  reading 
for  each  gage.  (More  detail  is  needed  on  this 
product  to  describe  station  computations  of  mean 
daily  flows  for  publication  from  telemetered 
data.)  See  Figure  5-25. 

5. 3. 4. 1.6  Monthly  Hydropower  Reports.  Tabular 
report  of  daily  generation  for  any  or  all  SWD 
projects  with  hydropower.  Include  total  minimum, 
maximum  and  mean  energy.  For  storage  projects 
compute  energy  in  storage  at  the  beginning  and  end 
of  the  month.  See  example  on  Figure  5-26. 
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5.3.4. 1.7  Annual  Lake  Report.  Tabular  or  graph¬ 

ic.  Annual  reports  of  project  data  are  used  in 
several  reports  with  varying  formats.  The  reports 
may  contain  average  monthly  inflow,  and  release; 
maximum,  minimum  and  end  of  the  month  pool  eleva¬ 
tion:  pool  contents  at  end  of  month;  basin  month¬ 

ly  average  rainfall  and  yearly  totals.  The 
program  should  update  the  average  monthly  inflow, 
release  and  basin  rainfall  for  the  period  of  rec¬ 
ord  and  print  for  comparison.  One  format  is  a 
tabular  report  of  midnight  lake  contents  for  USGS 
publications.  Examples  are  shown  on  Figures  5-28 
and  5-29. 

5.3.4. 1.8  Annual  River  Report.  Similar  to  annual 
lake  report  showing  maximum  and  minimum  monthly 
stage,  monthly  total  rainfall  and  long-term  aver¬ 
age  rainfall.  Also  computation  and  displays  in 
USGS  formats  for  publication.  See  Figure  5-30. 

5.3.4. 1.9  Other  Annual  Report  Products.  These 
products  are  required  annually  for  inclusion  in 
the  SWD  Reservoir  Control  Center  Annual  Report. 
Samples  of  the  products  are  shown  on  Figures  5-31 
through  5-33.  These  products  include:  (a)  a  table 
displaying  the  status  of  Water  Control  Manuals  for 
all  SWD  project  and  Section  7  projects  within  SWD; 
(b)  Annual  hydropower  production  at  a  SWD  power- 
plant;  total  SWD  projects  power  production  annual¬ 
ly  and  monthly  within  any  year  (historical),  (c) 
Bargraphs  of  total  annual  flow  for  any  flow  sta¬ 
tion  (updated  annually),  (d)  total  annual  inflow 
into  project,  (e)  Maximum,  minimum,  median,  mean 
flows  updated  annually,  (f)  Other  statistical  flow 
information  updated  at  an  event  and  annually  in¬ 
cluding  frequency  and  duration  analysis.  The  end 
products  are  too  numerous  to  list  here;  however, 
most  of  these  products  will  be  available  monthly 
as  the  data  base  is  verified  and  updated  and  annu¬ 
ally  updated  with  published  flow  information,  if 
available. 

5. 3. 4. 2  As  Required  Reports.  These  reports  are  produced 
on  an  intermittent  basis  depending  on  hydrologic  condi¬ 
tions.  Reports  range  from  flood  conditions  to  drought-low 
flow  conditions  reports.  Reports  are  generated  from  the 
data  base  accessing  output  from  previously  run  forecasts. 
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5. 3. A. 2.1  Flood  Conditions  Report.  Report  of 
current  flood  conditions  In  tabular  form  showing 
morning  stages  for  selected  stream  gages,  24-hour 
change  and  experienced  or  forecasted  peak  and  date 
for  the  current  event.  Maximum  stage  of  record 
and  date  are  also  included.  Reservoir-project 
data  include  current  elevation  and  24-hour  change, 
Inflow  and  outflow  for  past  24-hours,  peak  Inflow 
this  event  (either  experienced  or  forecasted)  and 
date,  experienced  or  forecasted  peak  pool  eleva¬ 
tion  this  event  and  date,  and  maximum  of  record 
and  date.  One  format  for  each  district  will  be 
similar  to  tables  required  by  RR  500-1-1,  Appendix 
A.  Other  formats  for  internal  distribution  will 
be  furnished  by  districts.  Figures  5-34  and  5-35 
are  examples  of  this  report. 

5. 3. 4. 2. 2  Water  Supply  Accounting.  This  product 
should  be  automatically  initiated  as  soon  as  the 
data  for  the  monthly  lake  report  data  are  veri¬ 
fied.  These  reports  show  the  volume  of  water 
withdrawn  by  each  user,  prorates  inflows,  losses 
and  evaporation  to  the  user  and  computes  each 
user's  remaining  storage  in  acre-feet  and  percent. 
The  report  is  prepared  at  the  end  of  any  month 
that  the  pool  is  below  the  top  of  conservation 
pool.  Computations  begin  from  the  date  the  pool 
receded  below  the  top  of  conservation  pool.  An 
example  of  the  output  is  shown  on  Figure  5-36. 

5. 3.4. 3  User  Selectable  Format  Reports.  These  are  reports 
which  can  be  created  to  serve  a  special  need  of  the  user. 
Generally,  these  would  be  created  using  the  AZ7  Query  Lang¬ 
uage  report  writer  to  extract  existing  data  from  the  master 
data  base.  These  data  can  then  he  displayed  in  a  format 
suitable  to  the  specific  user. 

5.3.5  Daily  Regulation  Products.  These  products  are  used  dally 
for  short-range  forecasts,  data  transfer  between  offices,  hourly 
operation  of  navigation  and  run-of-river  hydropower  projects,  and 
public  relations  information.  Products  in  this  group  involve  many 
of  the  day-to-day  water  management  activities. 


5.3.5. 1  Daily  Water  Budget.  This  is  the  basic  computation 
each  morning  by  project  regulators  to  check,  the  validity  of 
project  data  and  operations  for  the  previous  midnight  to 
midnight  period.  Once  the  project  operations  and  data  are 
verified,  it  is  then  acceptable  for  use  in  records,  files, 
and  reports.  The  program  should  perform  basic  computations 
for  inflows  minus  releases  and  losses  equal  change  in  stor¬ 
age  for  all  lake  projects.  Basic  data  would  include:  gate 
settings  for  spillways,  conduits,  valves,  etc.,  with  time 
of  gate  changes  and  headwater  and  tailwater  elevations, 
power  turbine  releases,  electrical  generation,  water  supply 
withdrawals,  evaporation,  leakage,  etc.,  and  necessry  rat¬ 
ing  tables  and  storage  tables.  Output  would  consist  of 
midnight  to  midnight  inflow,  releases  (total  and  by 
source),  losses,  change  in  storage;  midnight  and  7  a.m. 
storage,  7  a.m.  Instantaneous  releases;  time  and  magnitude 
of  gate  changes  and  resultant  instantaneous  releases  by 
source  and  total  along  with  headwater  and  tailwater  eleva¬ 
tions.  Output  to  be  filed  in  the  data  base  by  project  for 
later  retrieval  in  report  building  requirements.  Output 
would  be  flagged  in  event  of  unusual  data  or  imbalance  In 
budget  computations  so  the  project  regulator  can  coordinate 
any  needed  revisions  with  project  personnel  and  the  project 
data  base  manager. 

5. 3. 5. 2  Polling  Report.  Report  of  all  stations  for  which 
data  has  not  been  obtained  by  automatic  data  collection  and 
all  stations  reporting  data  which  did  not  pass  the  data  ed¬ 
iting  criteria.  Time  period  is  user  selectable  (last  4,  6, 
12,  or  24  hours  up  to  96  hours)  but  one  report  will  be 
automatically  printed  and  stored  each  morning  following  the 
7  a.m.  data  acquisition  and  screening. 

5. 3. 5.3  Dally  3-5  Day  Project  Inflows.  This  product  com¬ 
putes  daily  inflow  forecasts  for  all  projects.  Forecasts 
are  computed  as  soon  as  the  daily  water  budget  are  com¬ 
pleted.  Tandem  project  Inflows  are  computed  as  intervening 
area  flows.  Computations  are  based  on  a  normal  recession 
curve  for  each  site  unless  there  is  a  current  flow  forecast 
available  as  output  from  the  Reservoir  Inflow  and  Opera¬ 
tional  Forecast  module  (paragraph  5. 3. 3. 3).  Forecasts  will 
be  displayed  at  user's  request  and  may  be  altered  in  the 
display  mode.  User  verified  forecasts  are  stored  for  ac¬ 
cess  by  other  products. 

5. 3. 5. 4  Hydropower  Project  Inflow  Forecasts.  Hydropower 
project  inflow  forecast  for  5  days  are  furnished  to  the 
Southwestern  Power  Administration  (SWPA)  daily  for  their 
use  in  planning  hydropower  operations.  Output  from  the 
previous  product  for  hydropower  projects  only  is  tabulated 
and  printed,  then  stored  for  automatic  transmission  to  SWPA 
when  verified.  Output  is  a  1-page  table  showing  projects, 
previous  days  inflow  and  forecast  inflows  for  the  next  5 
days.  See  Figure  5-37. 
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5. 3. 5. 5  Power  Scheduling,  Dally.  This  file  will  be  updated 
daily  by  SWPA  and  may  be  accessed  by  all  districts.  File  will 
include  daily  generation  scheduled  for  current  day  and  the  next 
4  days  by  SWPA  for  all  SWD  hydropower  projects.  Reports  will 
include  project  names,  date,  generation  in  MWH  and  daily  dis¬ 
charge  in  day-second-feet. 

5. 3. 5. 6  Power  Scheduling,  Hourly.  These  schedules  are  pro¬ 
duced  daily  (5  days  per  week.)  for  projects  with  run  of  river 
hydropower  operations.  SWPA  will  initiate  a  forecast  file  of 
hourly  generation  from  the  present  until  midnight  of  the  fol¬ 
lowing  day  or  the  next  scheduled  work  day. 

5.4  Support  Requirements. 

5.4.1  Applications  Executive  -  supervises  overall  applications  of 
the  software  operation.  Schedules  and  controls  activities  and 
support  programs. 

5.4.2  Systems  Status  Monitor  -  monitors  applications  programs  for 
run  times  and  type  of  termination.  Abnormal  tertr*  nation  will  re¬ 
sult  in  logging  of  error.  Output  formatted  report  of  log  file 
upon  user  request.  Purge  or  archive  log  file  upon  user  request. 

5.4.3  Access  Monitor  -  user  Interface  with  VOS  operating  system 
and  applications  software.  User  friendly  language  with  menus  and 
prompts . 

5.4.4  Information  System  -  provides  information  on  applications 
software  and  allows  logging  of  user  comments.  Maintains  a  short 
or  complete  description  (user  selectable)  of  each  applications 
module.  Should  contain  information  regarding  contents,  functions, 
and  user  instructions. 

5.4.5  Training  System  -  provides  I/A  session  for  the  new  user  of 
applications  software  components  and  their  uses. 

5.4.6  Auto-Alert  -  notification  of  proper  personnel  of  events 
which  require  quick  action  such  as  heavy  rainfall,  high  flows  or 
equipment  failure.  Should  notify  proper  personnel  by  auto-dial 
according  to  a  List  of  alerts  and  responses. 

5.4.7  Task  Monitoring  System  -  maintains  and  displays  upon  re¬ 
quest,  work  schedules,  assignments,  and  status  of  various  water 
control  tasks. 

5.4.8  Simulation  and  Training  -  prepares  simulated  or  historical 
flood  emergency  exercise  data,  procedures,  and  reports.  Evaluates 
performance  of  required  water  control  functions. 
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5.4.9  Remote  Conferencing  -  enables  two  or  more  1/A  terminals 
within  the  SWD  WCDS  to  display  the  same  information  concurrent¬ 
ly  for  conference  purposes.  Shall  include  terminals  at  same 
site  or  different  sites. 

5.4.10  Message  Preparation  and  Exchange  -  prepares,  addresses, 
and  labels  messages  to  others  at  the  same  site  or  different 
site  and  schedules  messages  to  be  transmitted  at  a  later  time. 

5.4.11  Automatic  Reconfiguration  -  supports  automatic  reconfig¬ 
uration  of  applications  software  and  hardware,  in  cases  such  as 
a  single  processor  failure  at  a  dual  processor  site.  Contains 
fallback  and  recovery  procedures. 

5.4.12  Archiving  -  software  for  moving  all  or  part  of  files 
from  disc  to  tape,  recalling  flies  from  tape  to  disc,  copying 
files  from  disc  to  disc  and  maintaining  an  inventory  of  files 
by  tape. 

5.4.13  Data  Entry  -  Shall  support  manual  entry  via  interactive 
terminal  and  digitizer,  automatic  collection  of  GOES  data  from 
NESS  (self-timed  and  random-adoptive),  GOES  data  from  WES, 
DAROC,  NWS,  and  project  microcomputers  through  auto-dialer. 

5.4.14  Data  Screening  -  shall  be  performed  on  all  data  entry 
that  is  applicable.  Each  data  field  for  which  appropriate  up¬ 
per  and  lower  values  can  be  established  will  be  checked  to  en¬ 
sure  that  it  does  not  exceed  a  predefined  range.  Consistency 
checks  on  groups  of  data  elements  for  which  specific  arrange¬ 
ments  of  values  (cross  field  checking)  or  data  completeness  re¬ 
quirements  can  be  predefined  will  be  made.  After  range 
checking,  groups  of  data  elements  will  be  formed  into  records 
for  subsequent  update  of  the  data  base  at  predetermined  inter¬ 
vals.  Sufficient  source  information  will  be  appended  to  the 
edited  update  records  to  allow  retrieval  to  correct  errors 
found  subsequent  to  data  base  update  processing. 

5.4.15  Data  T  isf er  -  prepares  a  group  of  predefined  data  ele¬ 
ments  and  automatically  transmits  them  to  another  site  by  auto¬ 
dial.  Initiation  shall  be  either  automatically  upon  a 
predetermined  clock  time  or  user  request.  Data  transfer  re¬ 
quirements  will  be  site  to  site  within  SWD,  division  to  LMVD, 
districts  to  fWS,  all  sites  to  field  microcomputers,  etc. 

5.4.16  Auto-Dial .  Capability  to  auto-dial  des  ,  ated  sites  via 
phone  and  retrieve  or  transmit  ds-';a.  Auto-dj  1  to  be  clock 
driven  or  user  activated  from  a  terminal. 
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5 . 5  Special  Requirements. 

5.5.1  Albuquerque. 

5. 5. 1.1  Map  Overlay  -  contour  map  overlay  of  mountainous  areas 
in  addition  to  the  overlays  described  in  paragraph  5.2. 1.9. 

5.5. 1.2  Basin  Diagram  ~  line  diagram  of  basin  with  reservoir 
data  and  Llow  at  key  station.  Should  be  user  selectable  for 
report  type  (TTY  hardcopy  or  TTY  graphics  terminals).  Figure 
5-38. 


5.5.2  Fort  Worth. 

5.5.2. 1  Texas  Water  Commission  -  tabular  report  (monthl  ) 
showing  end  of  month  pool  elevations  and  storage  for  all  proj¬ 
ects  in  State  of  Texas.  Figure  5-39. 

5. 5. 2. 2  Mater  Diversion  (li.S.G.S.)  -  annual  tabular  report  of 
monthly  water  supply  diversions  in  acre-feet.  Figure  5-40. 

5. 5. 2.3  Dallas  Mater  Utilities  -  monthly  tabular  report  of 
water  supply  withdrawn  from  the  Trinity  Lakes.  Figure  5-41. 

5.5.3  Galveston . 

5.5. 3.1  Coastal  Tides  Map  -  map  plot  of  observed  coastal 
t  ides . 

5. 5. 3. 2  Navigation  Channel  Forecast  -  tabuLar  and/or  graphical 
report  of  velocity  and  stage  forecasts  in  navigation  channels. 

5.5. 3.3  Tide  Forecast  -  tabular  and  graphical  report  of  tide 
forecast . 

5.5.4  Little  Rock.  -  user  selectable  (graphics  terminal  or  drum 
plotter)  plot  of  steady-state  and  instantaneous  water  surface  pro- 
f lies . 


5.5.5  Tulsa . 


5.5.5.  1  Holdouts  -  tabular  report  of  Van  Buren  and  Fulton 
holdouts  to  be  transmitted  to  Little  Rock  District. 

5. 5. 5. 2  TAPER  -  user  selectable  (graphics  or  tabular)  report 
of  reservoir  outflows  necessary  to  meet  target  flows  at  Van 
Buren  based  on  Individual  guide  curves  and  balancing  scheme. 
Figure  5-42. 

5.5.5. 3  F  lood_  Benefits  -  tabular  annual  report  Including  flood 
benefits  for  Bureau  of  Reclamation  projects. 
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5.5.6  SWDO. 


5.5.6. 1  Lakes  In  Flood  Pool  -  tabular  report  of  all  lakes 
within  SWD  that  are  in  flood  pool,  including  project,  pool  ele¬ 
vation,  inflow,  outflow,  percent  of  flood  pool  occupied. 

5. 5. 6. 2  River  Stations  Above  Floodstage  -  tabular  report  of 
all  river  stations  above  floodstage  or  regulating  discharge,  to 
include  station  name,  floodstage,  last  reported  stage  and  fore¬ 
casted  peak  and  time. 
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Example 


WATER  CONTROL  MENU  LR-1 

SELECT  DESIRED  BASIN 

A  WHITE  RIVER  BASIN 
B  BUFFALO  RIVER 

C  NORFORK  RIVER 

D  BLACK  RIVER 

E  LITTLE  RED  RIVER 

F  ARKANSAS  RIVER  BASIN 

G  PET I  JEAN  RIVER 

H  FOURCHE  LA  FAVE  RIVER 

J  RED  RIVER  BASIN 
K  LITTLE  RIVER 

L  ROLLING  FORK 

M  COSSATOT 

N  SALINE 


Figure  5-i 


Example 


WATER  CONTR 


MEN 


LR-W- 


WHITE  RIVER  BASIN 


SELECT  DESIRED  PROJECT  OR  LOCATION 


BEAVER  DAM 


CLEARWATER  DAM 


TABLE  ROCK  DAM 


MOUTH  OF  BLACK  RIVER 


OZARK  BEACH  DAM 


NEWPORT 


BULL  SHOALS  DAM 


AUGUSTA 


MOUTH  OF  CROOKED  CREEK 


MOUTH  OF  LITTLE  RED  RIVER 


MOUTH  BUFFALO  RIVER 


DES  ARC 


NORFORK  DAM 


CLARENDON 


:alico  ROCK 


NORRELL  DAM 


SYLAMORE 


MOUTH  OF  WHITE  RIVER 


Figure  5-2 


Example 


To  display  a  single  parameter  enter  the  STATION  NAME  and  PARAMETER. 
Enter  : 

FORT  GIBSON; ELEVATION 
Displays : 

7  JUN  82  1422  FORT  GIBSON 

TIME  ELEVATION 
1415  552.42 


Example 

To  display  several  parameters  for  a  station  enter  STATION  NAME  and 
PARAMETERS. 

Enter  : 

DARDANELLE; ELEVATION, TURBINE  DI SCHARGE , TA I LWATER , TOTAL  DISCHARGE 
Displays  : 

25  JUL  82  1027  DARDANELLE 


ELEVATION 

TURB  DISCH 

TA I LWATER 

TOT  DISCH 

337.24 

12,400 

287.43 

12,400 

1015 

1000 

1015 

1000 

Example 

To  display  all  parameters  for  a  station  enter  STATION  NAME, ALL 
Enter  : 

AB I QU I U  , ALL 
Displays : 

7  JUN  82  0935  ABIQUIU 


TIME 

ELEVATION 

GATE  SETTING 

RELEASE 

INFLOW 

RAIN 

EVAP 

TEMP 

POOL  TAILW 

#1 

#2 

MN-MN  MN- 

1 

0700 

0.35 

6160.54  6031.96 
68 

0.8 

0.8 

493 

480  520 

0.06 

I 

1 

Figure  5-3 


Example 


To  display  time  series  data  for  a  single  parameter  at  a  single 
project 

enter  STATION  NAME  and  PARAMETER. 

Enter  : 


WHITNEY, HOURLY  GENERAT ION  ,  24 
Displays : 

25  JUL  82  WHITNEY  GENERATION (MWH) 


TIME 

UNIT  1 

UNIT  2 

TOTAL 

1000 

0 

0 

0 

1100 

20 

0 

20 

1200 

15 

15 

15 

1300 

15 

15 

30 

1400 

15 

15 

30 

1500 

15 

10 

25 

1600 

15 

5 

20 

1700 

15 

0 

15 

1800 

10 

0 

10 

1900 

2 

0 

2 

2000 

0 

0 

0 

2100 

0 

0 

0 

2200 

0 

0 

0 

2300 

0 

0 

0 

2400 

0 

0 

0 

TOTAL 

122 

60 

182 

0100 

0 

0 

0 

0200 

0 

0 

0 

0300 

0 

0 

0 

0400 

0 

0 

0 

0500 

0 

0 

0 

0600 

0 

5 

5 

0700 

0 

15 

15 

0800 

2 

15 

17 

0900 

15 

15 

30 

Figure  5-4 


Example 


To  f'.isplay  multifile  parameters  for  a  single  station 
nt  •  r  P'l  'Tie:;  \’A”E;  PAR^METEF/S. 


Enter : 

DARDANELLE; GENERATION, POOL: 


Displays  : 

25  JUL  82  1522  DARDANELLE 

TIME  UNIT-1  UNIT-2  UNIT-3  UNIT-4  TOTAL  ELEVA 


0100 

0200 

0300 

0400 

0500 

0600 

0700 

0800 

0900 

1000 

1100 

1200 

1300 

1400 

1500 

1600 

1700 

L800 

1900 

2000 

2100 

2200 

2300 

2400 

TOTALS 


0000 

0100 

0200 

0300 

0400 


0 

0 

0 

0 

0 

337.23 

0 

0 

0 

0 

0 

337.30 

0 

0 

0 

0 

0 

337.33 

0 

0 

0 

0 

0 

337.35 

0 

0 

0 

0 

0 

337.40 

3 

0 

0 

0 

3 

337.43 

25 

0 

0 

0 

25 

337.43 

29 

18 

0 

0 

47 

337.44 

35 

35 

0 

0 

70 

337.43 

35 

35 

0 

0 

70 

337.44 

35 

35 

0 

0 

70 

337.45 

35 

35 

0 

0 

70 

337.45 

35 

35 

0 

0 

70 

337.44 

35 

35 

22 

0 

92 

337.40 

35 

35 

35 

0 

105 

337.35 

35 

35 

35 

0 

105 

337.33 

35 

35 

35 

0 

105 

337 .33 

30 

30 

30 

0 

90 

337.33 

30 

30 

30 

0 

90 

337.30 

30 

20 

20 

0 

70 

337.30 

35 

35 

35 

0 

105 

337.28 

27 

26 

26 

0 

79 

337.28 

19 

17 

12 

0 

48 

337.30 

24 

0 

0 

0 

24 

337.31 

567 

491 

280 

0 

1338 

0 

0 

0 

0 

0 

337.35 

0 

0 

0 

0 

0 

337.38 

0 

0 

0 

0 

0 

337.42 

0 

0 

0 

0 

0 

337.45 

0 

0 

0 

0 

0 

337.49 

Figure 


Example 


To  display  several  parameters  for  two  or  more  stations  enter 
STATION 

NAME;  PARAMETER/S:  STATION  NAME;  PARAMETER/S. 


Enter : 

DARDANELLE; GENERATION, POOL: DAM- 9; POOL , RELEASE 


Displays : 

25  JUL  82  1522  DARDANELLE  LOCK  AND  DAM  9 


TIME 

UNIT-1 

UNIT-2 

UNIT-3 

UNIT-4 

TOTAL 

ELEVA 

F.uEVA 

RELEASE 

0100 

0 

0 

0 

0 

0 

337.23 

286.80 

6300 

0200 

0 

0 

0 

0 

0 

337.30 

286.83 

9800 

0  300 

0 

0 

0 

0 

0 

337.33 

286.45 

9800 

0400 

0 

0 

0 

0 

0 

337.35 

286.34 

9800 

0500 

0 

0 

0 

0 

0 

337.40 

286.29 

9800 

0600 

3 

0 

0 

0 

3 

337.43 

286 . 15 

9300 

0700 

25 

0 

0 

0 

25 

337.43 

286.00 

9300 

0800 

29 

18 

0 

0 

47 

337.44 

286.00 

9300 

0900 

35 

35 

0 

0 

70 

337.43 

286.15 

14600 

1000 

35 

35 

0 

0 

70 

337.44 

286.15 

14600 

1100 

35 

35 

0 

0 

70 

337.45 

286.32 

14600 

1200 

35 

35 

0 

0 

70 

337.45 

286.43 

14600 

1300 

35 

35 

0 

0 

70 

337.44 

286.43 

14600 

1400 

35 

35 

22 

0 

92 

337.40 

286.53 

14600 

1500 

35 

35 

35 

0 

105 

337.35 

286.60 

14600 

1600 

35 

35 

3  r 

0 

105 

337.33 

286.72 

14600 

1700 

35 

35 

35 

0 

105 

337.33 

286.81 

21400 

1800 

30 

30 

30 

0 

90 

337.33 

287.00 

21400 

1900 

30 

30 

30 

0 

90 

337.30 

287.11 

26900 

2000 

30 

20 

20 

0 

70 

337.30 

286.93 

26900 

2100 

35 

35 

35 

0 

105 

337.28 

286.86 

26900 

2200 

27 

26 

26 

0 

79 

337.28 

286.77 

26900 

2300 

19 

17 

12 

0 

48 

337.30 

286.80 

26900 

2400 

24 

0 

0 

0 

24 

337.31 

286.64 

17400 

TOTALS 

567 

491 

280 

0 

1338 

AVG  DISCH 

16067 

0000 

0 

0 

0 

0 

0 

337.35 

286.44 

17400 

0100 

0 

0 

0 

0 

0 

337.38 

286.34 

17400 

0200 

0 

0 

0 

0 

0 

337.42 

286.23 

17400 

0300 

0 

0 

0 

0 

0 

337.45 

286.11 

14600 

0400 

0 

0 

0 

0 

0 

337.49 

285.95 

14600 

Figure  5-6 


Example 


To  display  multiple  paramerter,  time  series  data  for  a  watershed 
enter  WATERSHED  NAME;  PARAMETER/S;  TIME. 


Enter:  JRED2,  PRECIP,  STAGE,  30  HR 


INCREMENTAL  PRICF 


STATION 

WEIGHT 

0700 

1300 

0100 

0700 

TOTAL 

Saf fordville 

.01 

0.00 

0.01 

0.50 

1.00 

1.51 

Dunlap 

.33 

0.00 

0.00 

0.60 

1.10 

1.70 

Diamond  Springs 

.01 

0.00 

0.05 

0.80 

1.50 

2.35 

Wilsey 

.15 

0.00 

0.00 

1.00 

2.00 

3.00 

Council  Grove  Dam 

.20 

0.00 

0.00 

0.95 

1.80 

2.75 

Chalk 

.16 

0.00 

0.00 

0.60 

1.30 

1.90 

Bushong 

.11 

0.00 

0.00 

0.20 

0.80 

1.00 

Basin  Av 

0.00 

0.00 

0.67 

1.37 

R.S. 

0700 

2300  0100 

0300 

0330  0530 

0615 

0630 

Council  Grove  lA.O 
Americus  27-5 

8.0 

1.9 

5.2  — 

5.1 

5-6 

5~8 

8.0 

6.0 

Figure  5-7 


*EOR  30  YEAR  PERIOD  1946- 19/5. 


Kxa-nplo  :  btroamf  low  forecast 


t  i  ’'it: 


1  ’  * ’x  "p!-.  shows  a  :  i  splay  of  the  observed 
forecast  flows  at  a  single  station.  The  capability 
to  show  the  individual  flows  tbit  make  up  the  total 
a  ydrofj  ra.  ..  is  r  equ  r  o<l .  The  various  comoonent 
hydrogranhs  can  he  shown  using  color  or' shading. 

The  user  should  have  the  capability  to  adjust  the 
forecast  curves  via  use'  of  the  grannies  oen. 


Example  :  Reservoir  inflow  fonvast.. 


TIM  K 

t 


This  -'x  i~-.pl  shows  a  graphical  display  of  the 
observe!  am!  forecast  inflows,  pool  elevations  and 
outflow  for  a  rt'scrvour.  Also  shown  is  the  control 
point  flow.  The  user  shall  have  the  capability  to 
alter  and  rerun  the  forecast . 
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ASSUMED  CONDITIONS  --  RUN  12  DATED  01-20-81 
100.0  PERCENT  MEDIAN  INFLOW 

70.0  PERCENT  GUIDE  CURVE  USED  THIS  MONTH-14  RESERVOIR  SYSTEM 
0.  PERCENT  GUIDE  CURVE  USED  THIS  MONTH-  2  RESERVOIR  5YSTIM 
99.2  PERCENT  FULL  ON  2-  1-1983  <  S  T  ART  I NG  PATE) 


GHZIlIin  39W01S  NISVH  dO  lN33H3d  IN31VA1 DD3 

PLATE  A 


Figure  5-1 


W  000  TO  20,000  tFS 


LITTLE  ROCK  DISTRICT 
RESERVOIR  REPORT  FOR  MON  4  OCT  82 


RESERVOIR 

POOL 

24-HOUR 

STORAGE  USED  24-HOUR  RAIN 

F.LEV 

CHANGE 

A-F  PERCENT  AVERAGE 

0800 

A-F 

OUTFLOW  INFLOW 

WHITE  1 

RIVER  BASIN 

BEAVER 

1113.18 

-777. 

-184638. 

-20. 

175. 

-148.  0.101467262 

TABLE  ROCK 

916.47 

-1760. 

-23320. 

-2. 

1170. 

399.  0.002765680 

BULL  SHOALS 

656.43 

2820. 

-26790. 

-2. 

450. 

1759.  0.003159210 

NORFORK 

543.84 

-3382. 

-170384. 

-24. 

2205. 

454.  0.001080816 

GREERS  FERRY 

452.66 

-290. 

-252360. 

-35. 

220. 

297.  0.201658140 

CLEARWATER 

515.97 

708. 

53333. 

14. 

1730. 

276.  0.08  76534 

ARKANSAS  RIVER  BASIN 


BLUE  MOUNTAIN 

384.26 

-61. 

796. 

0. 

8. 

-14.  0.07 

25436 

NIMROD 

342.03 

-71. 

106. 

0. 

5. 

-2.  0.00 

29116 

<1 

LOCK  S,  DAM  13 

391.28 

-2640. 

-4752. 

-72. 

1840. 

462.  0.00 

54348 

OZARK 

371.88 

-970. 

-1164. 

-6. 

2040. 

1827.  0.00 

147236 

DARDANELLE 

336.78 

1272. 

-40496. 

-62. 

830. 

1887.  0.00 

445704 

LOCK  &  DAM  9 

285.07 

-1664. 

-10336. 

-65. 

2040. 

1295.  0.00 

54264 

TOAD  SUCK-L&D 

8 

265.09 

43. 

387. 

0. 

2040. 

2013.  0.00 

33387 

MURRAY  -L&D 

7 

249.86 

618. 

8858. 

0. 

1440. 

1688.  0.00 

95958 

D.D . TERRY-L&D 

6 

231.07 

-2024. 

322. 

0. 

1840. 

1254.  0.00 

49822 

LOCK  t>  DAM  5 

213.31 

360. 

2232. 

0. 

2040. 

2067.  0.00 

63532 

LOCK  f.  DAM  4 

196.03 

-1716. 

198. 

0. 

2540. 

1806.  0.00 

70598 

LOCK  4.  DAM  3 

182.28 

320. 

1120. 

0. 

1640. 

2541.  0.00 

47520 

LOCK  &  DAM  2 

162.35 

111. 

3885. 

0. 

1340. 

1507.  0.00 

113985 

LITTLE 

RIVER 

BASIN 

DEQUEEN 

427.37 

-36. 

-13792. 

-54. 

7. 

-6.  0.00 

21108 

GILLHAM 

486.03 

-17. 

-17494. 

-60. 

20. 

17.  0.00 

15536 

DIERKS 

523.53 

-38. 

-3232. 

-21. 

18. 

0.  1.39 

26418 

MILLWOOD 

259.12 

299. 

-2389. 

-2. 

160. 

697.  0.00 

202753 

Figure  5-19 


FORT  WORTH  DISTRICT  CORPS  OF  ENGINEERS 
RESERVOIR  REPORT  FOR  MON  4  OCT  82 


RESERVOIR  POOL  ELEVATIONS  MEAN  MEAN  DAILY  OUTFLOWS  RAIN  EVAP  0800  FLOOD  POOL 
FEET-MSL  INFLOW  TURBINE  PUMP  TOTAL  RELEASE  UTILIZED 

0000  0800  DSF  DSF  MGD  DSF  INCHES  CFS  %  A-F 

RED  RIVER  BASIN 


WRIGHT  PA1W 

224.58 

224.57 

-135 

0 

59.020 

593 

0.00  .15 

502 

BOB  SANDLIN 

0.00 

328.46 

-8 

0 

2.413 

4 

0.00  .15 

0 

LAKE  O  PINE 

228.77 

228.76 

-375 

0 

0.000 

200 

0.00  .15 

200 

CADDO 

0.00 

168.00 

113 

0 

0.000 

0 

0.00  .15 

0 

SABINE 

RIVER 

BASIN 

TOLEDO  BEND 

168.27 

168.27 

258 

30 

0.000 

174 

0.00  .19 

144 

NECHES 

RIVER 

BASIN 

SAM  RAYBURN 

159.93 

159.92 

361 

2250 

0.000 

2250 

0.00  .22 

0 

B. A.  STEINH 

75.44 

75.57 

2500 

0 

0.000 

2482 

0.00  .11 

2485 

TRINITY 

RIVER 

BASIN 

BRIDGEPORT 

0.00 

834.16 

185 

0 

0.000 

343 

0.00  .26 

343 

EAGLE  MOUNT 

0.00 

646.65 

306 

0 

0.000 

241 

0.00  .26 

241 

LAKE  WORTH 

0.00 

591.54 

177 

0118.820 

184 

0.00  .26 

0 

BENBROOK 

692.99 

692.99 

-8 

0 

0.000 

0 

0.00  .26 

0 

LEWISVILLE 

514.89 

514.87 

-86 

0 

19.263 

368 

0.05  .18 

337 

GRAPEVINE 

534.56 

534.56 

32 

0 

0.000 

30 

0.05  .18 

30 

LAVON 

490.65 

490.64 

-21 

0137.885 

213 

0.00  .12 

0 

RAY  HUBBARD 

434.27 

434.25 

189 

0 

0.000 

0 

0.00  .12 

0 

CEDAR  CREEK 

0.00 

319.71 

26 

0 

83.870 

130 

0.00  .23 

0 

NAVARRO  MIL 

422.67 

422.66 

1 

0 

6.157 

16 

0.00  .23 

6 

BARDWELL 

419.30 

419.30 

8 

0 

2.531 

4 

0.09  .21 

0 

BRAZOS 

RIVER 

BASIN 

POSSUM  KING 

996.88 

996.86 

361 

20 

0.000 

20 

0.00  .22 

20 

GRANBURY 

692.25 

692.25 

107 

0 

1.812 

5 

0.00  .24 

2 

WHITNEY 

529.47 

529.47 

49 

0 

0.000 

0 

0.00  .25 

0 

WACO 

452.78 

452.77 

23 

0 

28.223 

44 

0.00  .24 

0 

PROCTOR 

1160.31 

1160.31 

8 

0 

0.000 

25 

0.00  .21 

25 

BELTON 

593.14 

593.14 

40 

0 

27.311 

67 

0.00  .27 

25 

STILLHOUSE 

620.71 

620.71 

0 

0 

0.000 

0 

0.00  .34 

0 

GEORGETOWN 

789.91 

789.91 

3 

0 

0.000 

2 

0.00  .19 

2 

GRANGER 

503.41 

503.41 

10 

0 

0.000 

3 

0.00  .23 

3 

SOMERVILLE 

236.42 

236.42 

-43 

0 

2.703 

4 

0.00  .19 

0 

LIMESTONE 

360.90 

360.90 

-41 

0 

0.000 

2 

0.00  .22 

2 

COLORADO 

1  RIVER 

!  BASIN 

TWIN  BUTTES 

0.00 

1921.46 

0 

0 

0.000 

0 

0.00  .29 

46 

O.C.  FISHER 

1884.15 

1884.15 

30 

0 

0.000 

0 

0.00  .29 

0 

HORDS  CREEK 

1888.92 

1888.92 

0 

0 

0.300 

0 

0.00  .26 

0 

BUCHANAN 

0.00 

1012.47 

0 

0 

0.000 

0 

0.00  .00 

0 

MARSHALL  FO 

665.16 

665.14 

238 

381 

0.000 

381 

0.00  .20 

0 

GUADALUPE 

RIVER 

!  BASIN 

CANYON 

906.15 

906.14 

96 

0 

0.000 

80 

0.00  .24 

80 

Figure  5-20 


STATIONS  ABOVE  FLOOD 


13 


JUL 


82 


S T AT  ION 

FS 

STG 

CHNG 

WHITE  R.  BSN. 
AUGUSTA 

26 

26 

.8 

SUIDED-X 

DAILY  RIVER 


STATION  FS 

******  WHITE  R.  BSN . 

ST.  JOE  33 

CALICO  ROCK  19 

BATESVILLE  23 

BLACK  ROCK  14 

NEWPORT  26 

AUGUSTA  26 

GEORGETOWN 

CLARENDON  26 


******  ARKANSAS  R.  BSN 


PUEBLO 
GARDEN  CITY 
DODGE  CITY 

WICHITA  19 

BLACKWELL  26 

RALSTON  16 

PERKINS  11 

TULSA 

******  VERDIGRIS  R. 
ALTOONA  23 

FREDONIA  17 

INDEPENDENCE  36 

CLAREMQRE  38 

INOLA  42 

******  GRAND-NEOSHO 
AMERICUS  33 

FLORENCE  22 

PLYMOUTH  28 

I  OLA  15 

COMMERCE  15 

MUSKOGEE  35 

POTEAU  20 


REPORT  13  JUL  82 

STG  CHNG  DISCHG 
CFS 


***  *** 


3.9 

-.0 

140 

2.7 

.  4 

2480 

4.5 

3.8 

-  .5 

-  .5 

47 10 

3.6 

-1 .0 

9620 

26.8 

9.8 

33800 

15.3 

-1 .0 

16900 

****** 


2.5 

■  NA* 

3.2 

-  .  4 

7.0 

.  1 

13500 

10.7 

-  .0 

26400 

****** 

4 . 4 

-  .  1 

4.0 

.  1 

3.3 

-  .  0 

320 

7.0  - 

1 . 6 

2590 

25.4 

•NA* 

****** 

3.5 

.0 

3 . 1 

-.  1 

4.7 

-.2 

4 . 1 

-  .0 

580 

3.6 

-.8 

17.9 

•NA  • 

3.6 

.0 

Figure  5-21 


★  *  *  ★  ★ 


*  ★  ★  ★  ★ 


SWD 

**10/05/82  WEEKLY  ENERGY  REVISED  ** 

** 10/05/82  MONTHLY  ENERGY  REVISED  ** 

*****  LITTLE  ROCK  DISTRICT  ***** 
BV  IS  IN  ZONE  3.  TR  AND  BS  ARE  IN  SEASONAL  POOL  ZONE.  NF  AND  GF 
ARE  IN  ZONE  4.  FISHWATER  CRITERIA  IS  IN  EFFECT  AT  ALL  WHITE  RIVER 
PROJECTS.  CALICO  ROCK  TEMP.  FORECAST  -  89  84  82 

*****  TULSA  DISTRICT  ***** 

BROKEN  BOW,  DENISON,  AND  KEYSTONE  ARE  IN  ZONE  3... 

TENKILLER  AND  EUFAULA  ARE  IN  ZONE  4... 

MAINTAINING  MININUM  FLOW  BELOW  BROKEN  BCW  AND  TENKILLER.... 

*****  FORT  WORTH  DISTRICT  ***** 
SAM  RAYBURN  IS  GENERATING  40  HOURS  PER  WEEK. 

WHITNEY  IS  CURRENTLY  ON  FIRM  GENERATION. 

*****  S  W  P  A  ***** 

NO  NOTES  AT  THIS  TIME 


ENERGY  DECLARATION  AND  GENERATION 
MWH  FOR  MON.—  4  OCT  1982 


THIS  MONTH  :  THIS  WEEK 


: 

CARRY-  : 

AVAIL-  : 

GENER- : 

AVAIL-: 

GENER- : 

GENER. : 

ALLOW. 

:  TODAYS 

PROJECT  : 

OVER  : 

ABLE  : 

ATED  : 

ABLE  : 

ATED  : 

YDA.  : 

ELEV. 

:  ELEV. 

BEAVER 

0 

10500 

109 

2700 

1309 

36 

1107.3 

1113.18 

NORFORK 

-2700 

11200 

1428 

2400 

2340 

382 

539.3 

543.84 

GREERS  FERRY 

5900 

4100 

413 

900 

1116 

89 

448.8 

452.66 

TABLE  ROCK 

0 

31200 

944 

7300 

1609 

602 

910.5 

916.47 

BULL  SHOALS 

0 

47600 

933 

10500 

2189 

40 

650.5 

656.43 

KEYSTONE 

0 

4900 

269 

900 

807 

-2 

717.8 

720.79 

TENKILLER 

0 

1500 

313 

600 

502 

21 

619.9 

624.28 

EUFAULA 

1800 

600 

163 

300 

281 

-3 

577.4 

580.39 

DEN  I  SON 

0 

9000 

889 

4000 

2148 

238 

612.2 

615.15 

BROKEN  BOW 

0 

4000 

-11 

900 

520 

-4 

583.5 

589.55 

SAM  RAYBURN 

0 

8100 

935 

2000 

2287 

314 

158.6 

159.92 

WHITNEY 

300 

2300 

51 

600 

577 

0 

526.5 

529.47 

STORAGE  PROJECT  TOTALS 

135000 

6436 

FT.  GIBSON 

3900 

51 

100 

121 

-3 

553.90 

WEBBERS  FALLS 

0 

-9 

0 

-22 

-3 

489.65 

R.  S.  KERR 

8100 

109 

1000 

714 

-7 

459.16 

OZARK  (L&D  12) 

0 

0 

0 

0 

0 

371.88 

DARDANELLE 

9900 

120 

1400 

1014 

40 

336.78 

RN-OF-RIVEP  TOTALS 

21900 

271 

TOTAL  ALLOCATION  156900 

TOTAL  GENERATION  6707  Figure  5-2 


NIMRDD  LAKE 

MONTHLY  RESERVOIR  REPORT 
JAN  82 


POOL  ELEVATIONS 

STORAGE 

RELEASES 

EVAF' 

MEAN 

RAINFALL 

DAY 

FT-MSL 

VOLUME 

DSF 

DSF 

INFLOW 

INCHES 

0700 

2400 

AC-FT 

POWER 

TOTAL 

DSF 

DAM 

DSN 

PRIOR  MONTH 

342.28 

30004 . 

1 

342.28 

342.27 

29969. 

0. 

70. 

5 

80  . 

0  . 

0  . 

2 

342.27 

342 . 39 

30394. 

0. 

70. 

4 

290. 

0. 

0.27 

3 

342.41 

342.48 

30714  . 

0  . 

70  . 

5 

180. 

1.13 

0.64 

4 

342 . 48 

342 . 46 

30643. 

0. 

70. 

4 

150. 

0.20 

0.05 

5 

342.46 

342.45 

30608  . 

0. 

120. 

11 

130. 

0. 

0  . 

6 

342.44 

342.41 

30465. 

0. 

220. 

6 

120. 

0. 

0  . 

7 

342.38 

342 . 33 

30182. 

0  . 

220. 

5 

120. 

0  . 

0  . 

8 

342.32 

342.27 

29969. 

0. 

220  . 

5 

100. 

0. 

0  . 

9 

342.25 

342.27 

29969. 

0  . 

220. 

5 

100  . 

0. 

0  . 

10 

342.25 

342.18 

29649  . 

0  . 

220. 

5 

100  . 

0  . 

0  . 

11 

342 .15 

342.06 

29223  . 

0  . 

220. 

5 

80. 

0. 

0  . 

12 

342.03 

342.07 

29258. 

0  . 

135. 

5 

160. 

0.04 

0.01 

13 

342.08 

342.10 

29365. 

0  . 

80  . 

5 

140. 

0 . 30 

0.21 

14 

342 .10 

342.10 

29365. 

0  . 

80. 

5 

120. 

0  . 

0.02 

15 

342.10 

342 . 12 

29436. 

0  . 

80  . 

5 

120. 

0. 

0. 

16 

342.13 

342. 13 

29472. 

o. 

80. 

5 

100. 

0. 

0  . 

17 

342. 13 

342. 13 

29472. 

0. 

80. 

5 

100. 

0, 

0. 

18 

342.13 

342. 14 

29507. 

0. 

80. 

5 

100  . 

0. 

0  . 

19 

342. 15 

342. 17 

29613. 

0  . 

80. 

5 

100  . 

0  . 

0. 

20 

342.18 

342.19 

29684 • 

0. 

80  . 

5 

100. 

0  . 

0  . 

21 

342.20 

342.24 

29862. 

0  . 

SO  . 

c 

U 

180.  ' 

0 . 15 

0.06 

o  n 

*-  *- 

342.32 

342.74 

31637. 

0  . 

80. 

cr 

sJ 

980  . 

0.70 

0.99 

23 

342.94 

343.62 

35183. 

o. 

80. 

6 

1870. 

1.40 

0.48 

24 

344.00 

344.58 

39243. 

0. 

80. 

6 

2130  . 

0. 

0  . 

25 

344.82 

344.28 

37974 . 

0  . 

1922. 

6 

1290  . 

0  . 

0. 

26 

343.90 

342.80 

31850  . 

0  . 

3800  . 

5 

300  . 

0. 

0. 

27 

342 . 38 

342.03 

29116 . 

0  . 

2232. 

5 

700. 

0  . 

0. 

28 

342.03 

342.06 

29223 , 

0  . 

473  . 

cr 

600. 

0  . 

0  . 

29 

342.12 

342.22 

29791 , 

0  . 

310. 

5 

600. 

0  . 

0  . 

30 

342.22 

343.  15 

33195. 

0. 

315  . 

6 

2004  . 

0 . 25 

0 . 45 

31 

343 . 90 

348.20 

57680  , 

0  . 

145. 

1 1 

12497  . 

2.05 

1 . 74 

TOTAL 

0. 

12012. 

177 

26141 . 

6 . 22 

4.92 

MEANS 

342 

.65 

0  . 

387  . 

6  . 

843  . 

MAX 

MN  348 

.  20 

57680. 

0  . 

3800. 

1 1 

12497  . 

MIN 

MN  342 

.03 

29116. 

0  . 

70, 

4 

80. 

INFLOW  VOLUME  FOR  MONTH  =  51851.  ACRE  FEET 
WATER  SUPPLY  WITHDRAWAL  FOR  MONTH  =  3.  D.S.F. 

UNACCOUNTED  LOSSES  FOR  MONTH  =  -4.  D.S.F. 


Figure  5-23 


LEGEND:  Ra<n  H  Snow 
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MONTH  0Fj>ECL“»Ef  195° 

GROSS 
STORAGE 
ELEV.  (ACRE  FT) 

Min  Pool  (WinloO  1010.0 _ 11,200 

Summor  Pool  1094.0 . 111,200 

Poll  Pool  .1*67  0 _ 289,600 

0u«;o«  Capacity  ol  Foil  Pool  -  40,000  el*. 


MONTHLY  reservoir  OPERATION 

TYGART  RESERVOIR 
M0N0NGAHELA  RIVER  BASIN 
DRAINAGE  AREA-  1184  SO  MILES 
ohio  river  division 

PITTSBURGH  DISTRICT 


finurc 


S  -  .>  4 


1 


HATE  £>t/25/83 

OCTOBER  1982 


RIVER  STAGES  (FEET) 


PAGE  10  OF  12 

SHEET  1 


♦ 

STATION 

(COPE 

SYMBOL 

USED 

FOR  NAME) 

« 

S  J0A4 

CLRA4 

B  A  T  A  4 

BNRA4 

NPTA4 

AUGA4 

GE0A4 

CRDA4 

1 

3 . 3 

3 . 0 

4 . 0 

- 

1 .0 

13.2 

1  .  2 

10.5 

o 

3 . 2 

3 . 6 

6 . 2 

2 . 4 

.  6 

13.2 

1  .  1 

10.3 

3 

3 . 2 

3 . 0 

6 . 5 

2 . 4 

2  .  1 

13.0 

- 

10.2 

4 

3  .  2 

3 . 2 

6 . 0 

2 . 5 

n  n 

13.8 

1 . 0 

10.1 

rr 

3 . 3 

5 . 3 

6 . 0 

2  *  b 

1  .  7 

1  .  4 

1 . 0 

10.0 

A 

- 

7  .  1 

8 . 0 

2  »  b 

1  .  7 

13.8 

1 . 5 

10.2 

7 

7 . 3 

10.8 

6 . 6 

5 . 0 

14.5 

2 . 9 

11.0 

8 

4 . 6 

Q  %  A 

5 . 1 

7  .  4 

17.7 

3.2 

11.5 

9 

2 . 3 

1  .9 

7 .8 

3 . 6 

6 . 4 

19.2 

3 . 9 

12.3 

10 

1  .  4 

5  .  o 

4  ,  ^ 

4 . 2 

18.2 

5 . 9 

13.4 

1  1 

~ 

1  .  2 

- 

4 . 6 

2 . 7 

16.4 

5 . 3 

14.0 

12 

2 . 4 

n  t 

4 . 0 

4 . 0 

1  .  9 

15.1 

5.2 

13.9 

13 

2  »  5 

5 . 8 

4 . 0 

4  .  2 

1  .  4 

14.4 

2.5 

13.1 

1  4 

2 . 4 

o  ^  -? 

6 . 2 

4 . 0 

1  .  3 

14.6 

- 

12.1 

15 

2 . 4 

4 . 0 

5 . 2 

3.8 

2  .  9 

15.0 

1  .  2 

11.3 

16 

2. 4 

4 . 5 

5  ♦  5 

3 . 6 

2 . 3 

14.5 

1  .  0 

10.7 

l  7 

2  .  4 

n  t  ~> 

b  •  b 

3 . 5 

n  n 

14.5 

1 .0 

10.5 

18 

2  .  4 

2 . 3 

b  ♦  5 

3 . 3 

'i  n 

14.4 

1  .8 

10.5 

19 

2 . 3 

4 . 3 

5  *  b 

3.3 

1  .  8 

14.1 

1 .9 

10.6 

2  0 

3 . 3 

1  .  3 

6 . 0 

3 . 2 

1  .  6 

13.8 

1  .9 

10.6 

21 

3 . 3 

3  .  1 

5 . 5 

3 . 0 

n  o 

13.8 

1.3 

10.4 

n  o 

3 . 3 

3 . 8 

5.5 

2 . 9 

1  .  7 

13.9 

1 . 3 

10 . 3 

23 

3 . 2 

2 . 9 

5  ♦  5 

2 . 9 

1  .  7 

13.7 

1 . 2 

10.2 

2  4 

3 . 2 

3 . 2 

c  c 

U  ♦  -J 

2 . 8 

1 . 6 

13.7 

1  .  3 

10.2 

25 

3 . 2 

3 . 0 

5  ♦  5 

2 . 8 

1 . 5 

1 . 3 

10.2 

76 

3 . 2 

1  .  8 

5  *  5 

2.8 

1 . 4 

13.5 

- 

10. 1 

7  7 

3 . 2 

2 . 6 

4 . 8 

2.8 

1  .  2 

13.5 

1 . 9 

10.0 

28 

3 . 2 

b  »  b 

7 . 0 

2 . 8 

.  9 

13.3 

.5 

9.9 

29 

3 . 3 

3.0 

7 . 9 

2 . 9 

1 .6 

13.0 

•  5 

9 . 7 

30 

3 . 2 

2 . 0 

5  •  5 

2.9 

2 . 6 

13.9 

•  5 

9.6 

31 

3  .  3 

6 . 8 

5.0 

2 . 9 

2.0 

14.2 

1 .3 

9 . 6 

NOTE:  STAGES  ARE  0700-HR  reapings 


MONTHLY  SUMMARY  Of  i UfFER  ZONE  OPERATION 
31 AV  E R 

NOV  32 


TOP  Cf  CONSERVATION  POOL-1120.00 


POOL  ELEVATION  AT  OOOC  HRS 

:  PELEASE  DSF 

CONS.  : 

ZONE  A  :  ZONE  S 

:  fLOOD 

EL2V.  :  ELEV. 

:  LIMIT  :  ELEV. 

.-LIMIT  ; 

E LEV.  : POWER  : 

SPILL 

1 1  10.  °9 

11 21 .00 

1 1  21 .00 

2  8  7C. 

0 

1110.73 

1121.00 

1121.00 

5 1  C . 

0 

1110.69 

1121 .00 

1  1  21  .CO 

15C. 

0 

1110.65 

1121 .00 

1 1  21  .CO 

1  7C . 

0 

11  1C. 60 

1121 .05 

1 121 .00 

20. 

0 

1110.57 

1121. Cj 

1121.00 

2C. 

0 

11 10.53 

1 1 21 .CO 

11 21 -CO 

20. 

0 

1110.59 

1 1 21 .00 

11  21  .CO 

190. 

0 

1110.61 

1 1 21 .CO 

11  21 .00 

2C . 

0 

1110.62 

1 1 21.00 

1  1  61  .00 

20. 

0 

1110.65 

11 21 ,C0 

1121.00 

2  C  . 

0 

1110.65 

1121. CO 

1121.00 

?C. 

0 

1110.60 

1121.00 

11  2 1  .  C  0 

2  C  . 

3 

1110.53 

1121.00 

1  1  2 1  .  C  0 

3  C . 

0 

1110.5a 

1121.00 

1121.00 

11  2C. 

0 

1110.56 

ii2i.ro 

1121.00 

9  SC  . 

3 

1110.33 

1121.00 

1  1  2  1  .  C  0 

5  3  C . 

0 

11 10. 3J 

11 21 .CO 

11  21  .00 

1 2C . 

3 

1110.56 

1121  .02 

11 2 1  . 0  C 

20  . 

3 

1 1  1C. 5  0 

1 1  2 1  .  C  0 

ii?i.ro 

2  C . 

O 

1110.59 

1121.00 

1121.00 

2  C  . 

0 

1110.59 

1121  .CO 

1121.00 

2C . 

n 

1110.57 

1121.60 

1 1 21 .CO 

:c. 

3 

1 1 1 0. 5  7 

1121.0 

1  1  1  C  0 

2C . 

3 

1110.6' 

1 1 :  i .  o : 

1121.20 

2C. 

0 

1110.66 

1121.00 

11:1.22 

0  r- 

■3 

11 1C.S5 

1 1  2 1  .  C  0 

11 21 .CO 

2C. 

0 

1111. A0 

11 21. CO 

1  1  2  1  .  C  3 

2  C . 

0 

1111.95 

1121.23 

1121.03 

2C. 

0 

1112.22 

1 1  2  1  .  C  C 

1 1 31 .00 

2  C . 

c 

S  JR 

-total  6370. 

0 

TOTAL  RELEASE 

6  370 
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Figure  5-28 


Pool  Content 


EUFAULA  RESERVOIR 


m  590 
2 


uj  580 


S  575 


J  A  S  O  N  D 


WISTER  RESERVOIR 


^  490 

2 


w  470 


5  460 


Figure  5  -  2  Q 


BRAIOS  RIVER  BASIN 


08782000  SALT  FORK  8RAZOS  fiver  near  asferhont.  tx 
(National  stream-qual ity  accounting  network) 

LOCATION. --Lat  33*20  02’.  long  i  00*  1  9  '  6  ".  Stonewall  County.  Hydrologic  Unit  12050007.  on  loft  bank  at  dcjvnatrtam 
aide  of  bridge  or,  U.S.  Highway  8)  5.5  ">1  (8.8  km)  downstream  from  Sale  Croton  Crack,  1J.2  ml  (21.2  km)  north 

of  Aapermont  and  at  mi  Le  2’. 3  (9J.9  wm)  measured  from  confluence  with  Double  Mountain  Fork  Brazoa  River  which 
Is  at  mile  923.2  (1  m85.m  *~)  on  t*-e  Brazo*  River. 

DR A INACE  AREA.--S,,3C  *"i  1  ('3,28’  of  which  2  6  34  ml  *  (6.822  k-')  probably  la  noncontributing. 

WATER- DISCHARGE  RECORDS 

PERIOD  OF  RECORD. --December  !92)  * o  August  1925  June  '9)9  to  current  year. 

REVISED  RECORDS  .  -  -WDR  T  X-ib-2  (halnage  area. 

CACE. --Water-stage  recorder  and  cre*r-afage  gage.  Oitjn  of  gage  la  1.588.10  ft  (489.236  m)  National  Ceodetlc  Ver¬ 
tical  Oatu*  of  1929.  .  5  '923.  to  Aug.  29  *925  nonrecording  gage  at  tlte  6.7  ml  (10.8  km)  downstream  at 

different  datum.  June  '6  '939.  to  July  ’J  1972  wjter-atag*  recorder  at  preaent  aite.  July  19,  1972.  to 

July  *9.  iy7S  at  aite  0.1  mi  (0.2  km)  upatream  at  tame  datum. 

REMARKS  .--Warer-dlsc^arge  record*  fair.  No  large  diversion  above  station.  Some  regulation  by  White  River  Reaer- 
volr  capacity  9-  900  acre-fc  <5‘>.9  h-*>.  ’Ob  M  (i?i  iir)  upstream.  For  atatement  regarding  regulation  by  Soil 
Conservation  Service  f  1  oo.lwa t  er  -  r  e:  ar-1  mg  acructurea.  ace  atetion  08080950. 

AVERACE  DlSCHARCE .- -9l  yeara  (water  yeats  1990-80)  Ml  ft*'a  (3.99  80  920  acre-ft/yr  (99.2  hm'/yr). 

EXTREMES  FOR  PERIOD  OF  RECORD -Maximum  discharge.  52  200  fr’/a  (  980  -"'a)  Sept.  25.  1955.  gage  height.  19.92 
ft  (9,598  "•) .  fro*"  racing  curve  extended  aho'-e  29.000  ft1  a  (82‘  n’/a),  no  flow  at  time*  mjst  yeara. 

Maxima*"  ataRe  since  at  least  1900  that  of  Sept.  25  '955. 

EXTREMES  OUTSIDE  PERIOD  OF  RECORD F loed  In  December  *91 3  reached  a  stage  of  19.9  ft  (9.39  m)  .  and  flood  In  Nov¬ 
ember  t939  reached  a  stage  of  ’3.7  ft  (9. '8  -) .  from  information  by  local  residents. 

EXTREMES  FOR  CURRENT  YEAR .- -Maximum  discharge  0  670  ft’,*  (296  p*  »  Mav  15  at  2300  hours,  gage  height.  7.59  ft 
(2.3‘3  m)  no  peak  above  base  of  1  000  ft'. ’a  ( 3-C  m1/*)  minimum  d  a  1 1  y .  0.C3  ft'/a  (0.001  m’/a)  for  many 

days  . 


DISCHaFCE  IS  CUBIC  FEET  fi'»  SECOND  WATER  YIAP  CCT-  PER  19’9  TO  SEPTEMBER  198C 
MEAN  VA1  F‘- 


DAY 

OCT 

NOV 

DEC 

Jan 

FF  9 

MAP 

APR 

“AY 

JCK 

JUL 

AX 

SEP 

, 

,, 

.0’ 

.76 

2.6 

'  .  - 

.Cm 

232 

26 

.  1  3 

.03 

2 

.  1  ! 

.08 

'  .9 

2  .6 

5.9 

2  .  9 

1  . 

'  5 

'•  59 

.25 

.09 

.03 

3 

*  1 

.09 

1  .0 

2 .  - 

M  .6 

3.  3 

•  66 

e . : 

.  20 

,C8 

.03 

4 

.09 

.  1  1 

.89 

2.3 

m.2 

3.9 

8» 

v5 

,’i0 

.09 

.03 

5 

.O’ 

.  !  1 

.89 

2.3 

9.0 

) .  1 

6  ) 

*' 

.  ’0 

.05 

.09 

6 

.0’ 

.’0 

1  .0 

2.3 

3.6 

2  .9 

.  5  b 

*•8 

.  C9 

.  C4 

.03 

7 

.07 

.  1  1 

1  .0 

2.0 

9.0 

2  .6 

.  36 

1 .  ’ 

60 

■  08 

.04 

.03 

8 

.06 

.  1  5 

l  .0 

2.1 

1  1 

2  .4 

.  :t 

.  8  7 

1  1 ' 

■  C  7 

.04 

.0- 

9 

.C  5 

.  1  2 

1  .0 

1  .7 

92 

2.3 

. .  ^ 

M  ' 

•  36 

.06 

.0) 

2  . 1 

1 0 

.C5 

.16 

l  .C 

1  .7 

19 

1  .9 

.  2  3 

.  V' 

•  TO 

’0 

.04 

8.5 

1  1 

.Cm 

.20 

1  .9 

1  .5 

r« 

2.2 

20 

.26 

350 

•  C9 

.04 

’  .0 

1  2 

.09 

.’8 

1  .8 

1  .9 

1  8 

2  .0 

.  1  ' 

24 

8  60 

.05 

.03 

.  1  7 

1  3 

•  Cm 

.  1  9 

20 

1  . 2 

18 

’  .5 

•  5 

'  ) 

?"5 

.05 

.04 

1  2 

1-4 

.05 

.’6 

12 

1  .  ’ 

1  5 

’  .5 

•  ) 

t  ’ 

205 

■  05 

.04 

9  .  ' 

15 

.0- 

.16 

1C 

.9  2 

14 

1  .  ) 

• 1  * 

90  B' 

.05 

.  C-4 

1  .8 

*6 

.15 

’.8 

.  9 

1  2 

»  .4 

.  1  • 

1  69; 

79 

.04 

.04 

.  35 

1  7 

.  0  9 

.1  7 

9.9 

.85 

9. 3 

1  .  1 

.  ■  0 

52  3 

61 

.09 

.  1  2 

.  21 

'8 

.09 

.19 

3.6 

1  .8 

9.2 

.  «\ 

.  1  ’ 

295 

36 

•  Dm 

.  32 

.18 

19 

.03 

.19 

2.9 

3.9 

7.8 

1  .0 

1  * 

193 

28 

.05 

.07 

.  1  ’ 

20 

.03 

308 

2.8 

5.9 

4.9 

.85 

.  1  1 

1  52 

29 

.05 

.04 

.13 

21 

h9 

1  78 

2.5 

70 

9.4 

.  6  - 

1  26 

1  7 

•  C6 

.06 

.M 

22 

!o« 

68 

2.1 

16 

3.6 

.90 

09 

9  1 

1  3 

12 

.03 

.  t  1 

2  3 

.09 

1  7 

2.5 

22 

2.9 

79 

’  0 

’  9 

8  .’ 

25 

.04 

.  2m 

29 

.09 

9  .  ’ 

3.2 

1  9 

2 .9 

. f  5 

.  06 

6' 

5  .  3 

2.8 

.04 

.  2  l 

25 

.09 

3.0 

3.7 

9  8 

2.9 

.7m 

06 

<5 

3.9 

1 

.0) 

26 

26 

•  Cl 

1  .  9 

3.6 

9.2 

2.9 

,7m 

•*,Q 

m6 

2  0 

’  .9 

.03 

1  88 

2  7 

.  h  5 

1  .9 

3.2 

7.8 

3.2 

*  .  3 

05 

41 

1 

.90 

.03 

toe: 

28 

.  06 

1  0 

7  .  1 

6.9 

2.9 

2  .5 

.  0  3 

38 

66 

63 

.10 

1  ’mC 

29 

.  V 

1  .0 

9.9 

6.5 

3.0 

2 . 7 

.04 

309 

.56 

.92 

.08 

955 

3C 

.09 

.89 

2.9 

6.5 

— 

1  .8 

.0* 

429 

.  39 

.  30 

.09 

3 1  ’ 

31 

1  n 

2 . 7 

6  .0 

... 

1  .9 

336 

.21 

.04 

TO  TAL 

1  .82 

587  .43 

’’5.09 

156.16 

255.9 

56.44 

8.7  5 

8589.98 

3  366  .  1  ' 

97.29 

i  .9) 

9JJ' . 2 4 

“LAN 

.CK  0 

’9  6 

3.71 

5.09 

8.82 

1  .82 

.29 

27  7 

1 1 : 

i  .52 

.06  2 

195 

“AX 

. 1  3 

308 

20 

22 

92 

3.9 

1  .4 

40*0 

860 

25 

.  32 

I  790 

“IV 

*  3 

0  ’ 

.  76 

.85 

2.9 

.65 

.0) 

.09 

.  39 

-0m 

-0) 

.03 

AC  -  FT 

3  .6 

1  l  70 

226 

310 

508 

i  '  2 

l  7 

1  70m0 

6680 

94 

3.8 

8600 

CAI  YR 

1  9 ’ 9  T^T 

A!  1 2  ?89 

95  ME.  AN 

35.0 

MAX  96  5 

MIN 

.03  AC 

FT  2'  360 

WTR  YR 

1980  TOT 

AL  i ’529 

09  MEAN 

97 .9 

MAX  9080 

MIN 

.  0  3  AC 

FT  39 '60 

Fiaure  5-30 


FOR  30  rpAR  PFR/OD  1946-  /9*5 


EL  ] 

DORADO  LAKE 

WATER  supply  storace  accounting 

total  conservation 

STORAGE 

154,100 

A.F. 

CONTRACTED  STORACE 

USER  #1 

31,900 

A.F. 

! 

CONTRACTED  STORAGE 

USER  *2 

33,450 

A.F. 

i 

CONTRACTED  STORAGE 

USER  J3 

88,750 

A.F. 

Beginning 

Inflow 

Total 

Ending 

Storage 

Share 

Losses 

Withdrawn 

Storage 

Month 

User 

A.  F. 

A.F. 

A.F. 

A.F. 

A.F. 

Jan 

Lake 

154,100 

90 

331 

972 

152,887 

i 

31,900 

19 

68 

476 

31,374 

2 

33,450 

20 

72 

496 

32,902 

3 

88,750 

52 

191 

0 

88,611 

Feb 

Lake 

152,887 

2  30 

789 

878 

151,450 

i 

31,374 

48 

161 

4  30 

30,831 

2 

32,902 

50 

169 

448 

32,335 

3 

68,611 

132 

459 

0 

88,284 

Mar 

Lake 

151,450 

80 

1,235 

972 

149,323 

1 

30,831 

17 

250 

476 

30,121  1 

2 

32,335 

17 

262 

496 

31,59a 

3 

88,284 

46 

722 

0 

87,608 

Apr 

Lake 

149,323 

70 

1,825 

941 

146,627 

1 

30,121 

14 

366 

461 

29,308 

2 

31,594 

15 

384 

480 

30,744 

3 

87,608 

40 

1,074 

0 

86,575 

Kay 

Lake 

146,627 

«C0  WAMvT  1 

EL  DORADO  LAKE 

WATER  SUPPLY 

STORAGE  ACCOUNTING 

1  OC’T.  O*  T«f  «ft«r  TUlfA  cur  CO»H  OP 

«  dll 

a.... 

D.V.  I 

1  CNICIID  Dll 

r 


Example:  Hydropower  Project  Inflow  Forecasts 

TO:  SWPA  DATE:  1/20/83  TIME:  0950 


INFLOW 

I  N  F  L  0 

W  FORECAST 

PROJECT 

YPA 

20 

21 

£_£_ 

23 

Bea ve r 

100 

100 

100 

100 

100 

Table  Rock 

800 

800 

Bull  Shoals 
Norfork 

1500 

IlOO 

1300 

1200 

Greers  Ferry 

500 

100 

300 

200 

200 

Ozark 

Dardanelle 

16000 

11 000 

12000 

12000 

Calico-Rock 

Temp 

Ozark 

Dardanelle 


*  *  # 


M  E  A  U 


A  I  L  Y  DISCHARGE*** 


V 

FORT 

FOR  Eli  DISTRICT  CORPS  OF 

ENGINEERS 

RESERVOIR  REPORT  FOR  TUE  26  OCT  82 

RESERVOIR  POOL  24-H^uR  STORAGE  USED  24-HOUR  RAIN 

ELtV  ChAUuE  A-F  PERCENT  AVERAGE 

0600  A-F  OUTFLOW  INFLOW 

R£0  RIVEn  BASIN 

'  wRIGHT  PATi-AN  223.53  -2686.  39053.  2,  889.  -252.  0.00 

22"810. 

[  BCd  SANDLIN 

32o.20  -”4.  -"621:. 

-39. 

6. 

-0.  0.00 

135152. 

LAKE  0  PINES 

225.54  0.  "4". 

0. 

25. 

64.  C."0 

255684. 

CAUOO 

166.30  0.  -5340. 

-4. 

0. 

54.  0.00 

123610. 

TuEEDO  BEND 

SABINE  RIVER  BASIIi 

loB.22  -8245.-6517"2. 

-15. 

1399. 

-5313.  0.  003625182. 

1  SAM  RAY BuRN 

NECHES  RIVER  BASIN 

159.44  -9113.-5346"0. 

-3". 

2696. 

-1813.  0.  002363339. 

6. a.  SieINHAGEN 

66.53  4534.  -89115. 

-95. 

1632. 

1009.  0.  00 

5135. 

BRIDGEPORT 

TRINITY  RIVER  BASIN 

833.24  -"  38  .  -34"3". 

-9. 

34  1. 

26.  0.00 

351832. 

EAvjLE  olOUNTAIN 

646.62  -166.  -20965. 

-1  1. 

163. 

116.  0.00 

168  5  5". 

i  LA al  wORTU 

591. "b  -Ho.  -631" . 

-22. 

101. 

56.  0.00 

293  31  . 

bLLBRjJOK 

692.6"  -"3.  -492  3. 

8. 

-11.  0.00 

8  3324  . 

LEwISVlLLE 

513.86  -6s6.  -260^6. 

-6 . 

214. 

-36.  0.00 

431585. 

GRAPEV  IGE 

534.10  -216.  -6492. 

“M  i 

30. 

-52.  0.00 

l"*4o  l"1. 

LAVUN 

490.23  -40".  -36"20 . 

-8. 

141. 

121.  0.00 

42010S. 

KAY  HUBBARD 
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DIVERSIONS  IN  ACRE-FEET  FOR  WATER  YEAR 
1  OCTOBER  1978  TO  30  SEPTEMBER  1979 


Crapevln*  Cm We 


City  of : 

Grapevine  Corsicana 

OCT  198  568 

NOV  110  967 

DEC  103  939 

JAN  108  503 

FEB  165  909 

MAR  106  992 

AFR  HI  433 

MAY  191  965 
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AEG  170  571 

SEP  204  599 
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29 
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46 

8 
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RELEASES  FROM  LEWISVILLE  AND  GRAPEVINE  RESERVOIRS 
(Acre-Feet ) 


Request  for.Releases 


by  the  City 
f  rom 

of  Dallas 
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Denton 
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Jun 
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83234 

1597 

839 
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215 
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894 
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11355 
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(1)  Computed  total 

releases . 

During  period 

when  the 

reservoirs  are  doi  in 

f looo- 

control  operation,  releases  are  made  to  conform,  as  nearly  as  practicable,  with 
requests  by  the  City  of  Dallas  from  the  Lewisville  Reservoir  and  with  the  com¬ 
bined  request  by  the  City  of  Dallas  and  the  Dallas  County  Park  Cities  Water 
Control  and  Improvement  District  No.  2  from  the  Grapevine  Reservoir. 


14  FEB  80  ".D.S. 


r'  -1  1 


F  l  u:  r  t' 


450 


VI.  SOFTWARE  DEVELOPMENT  TO  SUPPORT  USER  REQUIREMENTS. 


6.1  General.  The  purpose  of  Chapter  6  is  to  Identify  and  describe  in 
general  terms  the  Water  Control  Data  System  (WCDS)  software  necessary  to 
meet  the  water  control  user  needs  described  in  Chapter  5.  The  system  of 
software  consists  of  (1)  applications  software,  which  meets  primary  user 
needs,  and  (2)  support  software,  which  facilitates  the  integration  of 
applications  software  into  a  coherent  system  which  enables  effective 
user  interaction. 

The  following  material  is  Intended  to  provide  a  general  description  of 
the  components  of  the  software  system.  The  relationship  of  one  compo¬ 
nent  to  another,  the  general  flow  of  data,  and  output  product  from  each 
component  is  discussed.  Detailed  internal  design  of  programs  within  the 
components  is  not  within  the  scope  of  this  chapter. 

6.1.1  Applications  Software.  An  overview  of  the  WCDS  applications 
software  required  to  support  user  needs  is  shown  in  Figure  6-1. 

This  system  of  software  is  divided  into  three  main  groups  with  each 
group  containing  several  related  components  or  programs. 

a.  Acquisition  Group  (A).  This  group  contains  components  which 
provide  capabilities  for  acquisition  and  basic  processing  of 
time-variant  field  data  from  all  major  sources. 

b.  Database  Utility  Group  (B).  This  group  provides  essential 
database  management  capabilities,  report  generation,  and  dis¬ 
plays. 

c.  Analysis  Group  (C).  This  group  provides  the  basic  data 
analysis  tools,  such  as  forecast,  operation,  and  economic 
models.  Results  obtained  from  this  group  are  used  by  project 
managers  for  making  water  control  decisions. 

6.1.2  Support  Software.  Support  software  integrates  the  applica¬ 
tions  software  components  to  provide  a  user  friendly  system.  This 
includes  routines  for  program  and  computer  control,  database  inter¬ 
face,  records  of  system  operation,  and  communications. 

a.  Control  Routines  (Rl.  Control  routines  are  important  in  dy¬ 
namically  and  structurally  integrating  the  operations  of  indi¬ 
vidual  applications  components  into  a  coherent  system. 

Automatic  control  of  major,  routine  functions  is  a  primary  fea¬ 
ture  of  the  control  system.  Control  components  also  facilitate 
effective  interaction  between  users  and  software  components. 

b.  Database  Routines  (D).  Database  routines  provide  for  data¬ 
base  entry  and  internal  transfers. 

c.  Records  Routines  (L).  Records  routines  provide  Information 
on  system  performance,  a  basis  tor  troubleshoot i  g  system  prob¬ 
lems,  and  a  means  of  tracking  sequence  of  user-directed  opera- 

t ions . 


d.  Communications  (S).  These  routines  provide  for  messages, 
remote  conferencing,  and  inter-site  communications. 

6.1.3  Common  Software.  The  basic  needs  of  users  may  be  satisfied 
by  a  common  system  of  software.  The  common  system  provides  a 
framework  upon  which  site-specific  needs  may  be  built  if  required. 
Common  software  should  be  as  generalized  as  possible  and  should 
have  data  files  to  describe  unique  local  information.  In  other 
words,  program  code  should  not  be  designed  to  meet  only  specific 
user  needs.  Data  files  can  be  readily  changed  to  reflect  different 
user  requirements,  thus  avoiding  expensive  program  changes. 

In  certain  cases,  however,  data-driven  general  software  may  not  be 
appropriate,  and  specially  developed  software  may  be  required. 
Software  unique  to  specific  sites  is  discussed  elsewhere. 

6.2  Applications  Software.  A  schematic  diagram  of  these  groups,  their 
individual  component  programs,  key  related  files  and  their  interrela¬ 
tionships  are  shown  in  Figure  6-1.  Labels  on  the  figure  associated 
with  individual  groups  and  programs  correspond  to  references  in  this 
text. 

6.2.1  Acquisition  Group  (A).  The  Acquisition  Group  is  the  means 
by  which  basic  data  enter  the  system  from  sensors  in  the  field, 
observers,  or  other  external  sources.  For  example,  this  group 
retrieves  data  from  field  stations,  processes  the  data,  and  enters 
them  into  the  main  data  base.  Data  communications  programs  receive 
and  temporarily  store  small  amounts  of  data  from  various  field 
systems,  Including  Geostationary  Orbiting  F.nvi  ronmental  Satellite 
(GOES),  National  Weather  Service  (NWS)  s/140  computers,  and 
land-lines  as  well  as  from  manual  entry  by  field  observers.  The 
field  observations,  mainly  stage  and  cumulative  precipitation,  are 
converted  into  other  useful  data,  such  as  elevation,  streamflow, 
reservoir  storage,  and  incremental  precipitation,  and  are  then 
screened  for  validity  and  possible  exceedence  of  critical  values 
which  would  indicate  emergency  conditions.  Valid  data  observations 
are  then  placed  in  a  file  for  update  into  the  main  data  base. 

The  Acquisition  Group  requires  the  following  to  operate: 

a.  Communications  link  to  each  data  source  (GOES  downlink  man¬ 
ual  entry  terminal,  etc.). 

h.  List  of  valid  station  identifiers. 

c.  Scheduled  reporting  interval,  parameters,  data  collection 
platform  manufacturer,  valid  data  range,  data  alarm  values  for 
each  station. 

d.  Data  conversion  coefficients  for  stage-discharge,  stage- 
eievation,  stage-storage  as  appropriate. 
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The  output  from  tin  Acquisition  Group  is  a  standard,  formatted,  se¬ 
quential  text  tile  (01)  containing  partially  screened  data  in  reada¬ 
ble  engineering  units  with  appropriate  location,  parameter,  and  time 
labeis.  The  tile  tnay  be  listed  on  a  terminal  or  line  printer  if  de¬ 
sired.  This  file  is  used  as  input  to  update  the  data  base  (Dl). 

n.2.1.1  oOES  Communications  Program  (Al).  The  GOES  Comuiinica- 
tions  Program  receives  field  observations  from  a  Direct  Readout 
Ground  Station  (downlink)  and  writes  the  data  to  either  a  memory 
butter  or  an  intermediate  file  for  subsequent  processing  by  the 
Conversion  a  not  Screening  Program  (A8). 

Data  are  received  at  scheduled  or  random  intervals  depending 
upon  tlie  type  ot  data  collection  platform  at  the  field  station. 
Scheduled  reports  and  random  reports  are  made  on  separate  radio 
channels.  Random  reports  are  processed  at  higher  priority  than 
scheduled  reports  since  they  indicate  the  occurrence  of  critical 
events,  such  as  intense  precipitation  or  high  river  stage.  In 
most  cases  regardless  of  whether  the  report  is  transmitted  on  a 
fixed  schedule  or  at  a  random  time,  the  data  sample  itself  is 
actually  taken  at  a  regular  even  time  such  as  each  15  minutes,  1 
hour,  etc. 

Data  received  from  the  Direct  Readout  Ground  Stations  may  be  in 
either  engineering  units  or  non-readable  "binary"  form  depending 
on  the  data  collection  platform  manufacturer.  Data  observations 
passed  to  the  user  from  the  downlink  include  station  (DCP)  ID 
and  time  of  receipt  by  the  ground  station  as  well  as  the  mea¬ 
sured  variable  values. 

If  the  communications  link  between  the  ground  station  and  the 
communication  program  Is  active,  data  may  be  passed  from  the 
downlink  as  soon  as  It  Is  received.  If  the  communications  link 
is  inactive,  the  ground  station  must  hold  the  data  in  a  buffer 
file  until  the  link  is  re-established.  When  the  link  becomes 
active,  all  previously  received  data  must  be  sent  from  the  buf¬ 
fer  file.  The  design  of  the  ground  station  will  govern  whether 
data  buffering  may  be  performed.  If  no  buffering  takes  place  at 
the  ground  station,  the  communications  link  must  be  active  at 
all  times  to  preclude  loss  ot  data. 

This  program  Is  capable  of  utilizing  various  communications  pro¬ 
tocols  depending  on  the  downlink  site  and  whether  the  communica¬ 
tions  link  uses  a  dedicated  circuit  or  a  dial-up  circuit. 

With  a  dedicated  circuit  the  data  received  from  the  satellite 
can  he  passed  to  the  processor  immediately.  The  transmission 
rate  from  the  satellite  to  the  ground  station  is  only  110  bps  on 
each  channel,  so  several  channels  can  be  serviced  by  a  300  or 
1200  bps  transmission  line.  With  a  dial-up  circuit,  the  data 
must  be  stored  at  the  receive  site  when  not  connected ,  and  a 
backlog  or  data  may  accumulate.  A  high  t ransmission  rate  is 


preferred  in  transmitting  the  backlog  to  reduce  on-line  time. 
The  rate  required  is  dependent  on  the  interval  between  connec¬ 
tions  and  the  number  of  messages  accumulated.  For  dial  up, 
transmission  rates  from  1200  to  4800  bps  are  usually  necessary. 

At  transmission  rates  up  to  1200  bps,  simple  asychronous  proce¬ 
dures  may  be  used.  Therefore,  the  downlink  site  may  be  treated 
as  if  it  were  an  interactive  terminal  providing  data  to  the  re¬ 
ceiving  system,  even  if  it  is  actually  another  computer.  Spe¬ 
cial  multiplexors  and  modems  must  exist  at  each  end  of  the 
communication  Line  if  asynchronous  communications  are  to  occur 
at  speeds  greater  than  1200  bps.  If  such  equipment  is  used, 
speeds  of  4800  bps  may  be  achieved  on  dial-up  circuits  and  9600 
bps  on  dedicated  circuits.  Such  special  equipment  is  not  nor¬ 
mally  available  at  sites  and  must  be  specially  provided. 

Synchronous  communicat ions  can  readily  be  provided  at  rates  of 
4800  bps  for  dial  up  circuits  and  9600  bps  for  dedicated  cir¬ 
cuits.  (However,  with  synchronous  communication  a  communica¬ 
tions  protocol  must  be  used.  Various  such  protocols  exist, 
although  no  common  standard  may  be  expected  to  be  available  for 
communication  to  all  sites.  The  NOAA-NESS  downlink  allows 
dial-up  4800  baud  access  with  a  binary  synchronous  protocol 
unique  to  that  installation  hardware.) 

Communications  with  different  downlinks  are  achieved  with  sev¬ 
eral  separate  communications  programs,  rather  than  with  a  sin¬ 
gle  comprehensive  routine. 

Minimal  processing  is  done  by  the  communications  program,  and 
data  are  output  to  the  buffer  area  at  almost  the  same  rate  as 
they  are  received.  The  Data  Conversion  and  Screening  Program, 
on  the  other  hand,  may  process  data  at  a  slower  or  faster  rate. 
Consequently,  output  from  a  communications  program  is  saved  in 
either  a  memory  buffer  or  an  intermediate  file,  depending  on 
the  size  and  availability  of  the  memory  buffer. 

The  GOES  Communications  Program  is  initiated  either  by  user 
command  or  by  the  Master  Control  Program  (a  support  program), 
based  on  a  specific  time  interval.  The  routine  runs  as  a  real¬ 
time  program  at  priority  level  9  to  preclude  loss  of  data. 
Priority  leveis  used  herein  are  expressed  on  an  arbitrary  scale 
from  1  to  10,  where  10  is  the  highest  priority  available.  The 
output  from  the  GOES  Communications  Program  consists  of  trans¬ 
missions  from  the  DCP  and  from  the  downlink  station.  Some 
transmissions  require  translation  before  they  may  be  used  for 
any  purpose. 

6.2. 1.2  NWS  Communications  Program  (A2).  Provision  is  made 
for  Interface  to  WS  data  from  the  River  Forecast  Center  s/140 
computer  system.  In  general,  similar  capabilities  must  be 
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provided  for  NWS  s/140  communications  access  as  are  required  for 
GOES  access.  The  type  of  communication  access  (i.e.,  asynchron¬ 
ous  or  synchronous),  transmission  protocols,  transmission  speed, 
and  buffering  of  data  must  all  be  addressed. 

The  NWS  C jmmunicat ions  Program  must  enter  all  data  into  the  buf¬ 
fer  ar  'a  for  processing  and  subsequent  entry  into  the  data  base. 
The  output  consists  of  data  files  from  the  NWS  system.  These 
files  are  sequential  text  files  which  may  be  read  and  used  as  an 
intermediate  product.  The  tWS  Communications  Program  is  a  real¬ 
time  program  with  priority  level  9.  It  is  Initiated  by  the  Mas¬ 
ter  Control  Program  If  data  are  buffered  at  the  s/140  entry 
mode.  If  no  buffering  is  available,  it  must  be  on-line  continu¬ 
ously  . 

A  further  discussion  of  detail  s/140  access  is  not  possible 
without  specifications  of  local  Corps  requirements  at  each  re¬ 
spective  site. 

6.2. 1.3  Land  Line  Communications  Program  (A3).  Various  devices 
exist  for  obtaining  remote  instrument  readings  by  use  of  equip¬ 
ment  attached  to  standard  dial-up  voice  telephone  equipment. 
Telemark's  and  DARDC's  are  examples  of  such  devices  in  use  by 
the  Corps.  Some  COES  data  collection  platforms  are  also  adapta¬ 
ble  for  telephone  access.  Each  of  these  devices  requires  a  syn¬ 
chronous  communications.  Information  sent  from  the  field  site 
may  be  in  directly  machine  readable  form  (DARDC  sites),  or  may 
require  processing  by  specially  designed  Interface  hardware  and 
software  (Telemark  sites)  at  the  receiving  site. 

The  Land  Line  Communications  Processor  is  capable  of  placing  re¬ 
ceived  data  in  the  buffer  area  for  processing  and  subsequent  in¬ 
put  Into  the  data  base. 

It  Is  a  real-time  program  at  priority  level  9.  Initiation  is 
made  by  the  Master  and  Controi  Program  at  specific  intervals. 

It  may  also  be  initiated  upon  demand  of  the  user.  The  output 
from  the  Land  Line  Communications  Program  is  transmissions  from 
land  line  stations. 

6. 2. 1.4  Manual  Data  Entry  Program  (A4).  The  Manual  Data  Entry 
Program  facilitates  entry  of  data  observations  via  interactive 
terminals  at  the  local  site  or  at  remote  locations,  such  as 
project  offices.  The  program  is  structured  to  respond  to  a  sim¬ 
ple  set  of  data  entry  commands.  Entries  are  screened  for  com¬ 
pleteness  and  simple  validity,  such  as  checks  for  non-valid 
characters.  Where  errors  are  detected,  the  user  is  informed, 
allowing  immediate  re-entry  of  correct  values.  Entries  include 
location,  variable  Identification,  variable  value,  and  time  of 
observation.  The  program  normally  executes  Interactively,  at 
priority  level  5.  It  is  initiated  by  user  request.  It  may  also 
be  run  In  batch  mode  where  data  are  read  from  a  previously  pre¬ 
pared  data  file.  Simultaneous  executions  from  several  sites  are 
permissible  since  each  project  file  writes  to  its  own  memory 
buffer  or  Intermediate  file. 
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6.2. 1.5  Inter-computer  Data  Link  (A5).  The  Inter-computer  Data 
Link  is  associated  with  the  input  of  a  file  that  has  been  sent 
to  the  host  system  from  some  remote  site.  A  description  of  this 
function  is  given  in  paragraph  6. 2. 2. 5. 

6.2. 1.6  Satellite  Imagery  Communications  (A6).  The  Satellite 
Imagery  Communications  routine  provides  for  the  entry  of  a 
satellite  image  from  a  downlink  station  supporting  imagery 
data.  The  routine  provides  the  necessary  protocol  to  establish 
connections  to  initiate  transmission  of  data  from  the  downlink. 
The  image  is  received  in  digital  form  and  passed  to  the  Imagery 
Entry  Processor  (All)  for  preparation  for  entry  into  the  data 
base . 

6.2. 1.7  Radar  Imagery  Communications  (A7).  The  Radar  Imagery 
Communications  routine  provides  for  the  entry  of  radar  scans 
from  a  NWS  radar  site.  The  routine  provides  the  necessary  pro¬ 
tocol  to  establish  connections  and  initiate  transmission  of 
data  from  the  radar  site.  The  scan  is  received  in  digital  form 
and  passed  to  the  Imagery  Entry  processor  in  preparation  for 
entry  into  the  data  base. 

6 . 2 . 1 . 8  Data  Conversion  and  Screening  Program  (A8).  The  Data 
Conversion  and  Screening  Program  processes  data  observations 
that  have  been  placed  in  its  buffer  area  by  any  of  the  GOES, 
fMS,  land  line  or  manual  data  entry  routines. 

The  program  first  translates  the  observation.  Some  of  the  ob¬ 
servations  are  reported  in  a  standard  format,  others  are  re¬ 
ported  in  special  codes  that  require  bit  manipulation  to 
translate. 

In  order  to  perform  translation  operations,  information  about 
the  field  site  is  obtained  from  the  Site  File  (A9)  which  also 
contains  information  on  the  parameters  expected,  transmission 
times,  etc.  Next,  the  observation  is  converted  from  expression 
on  an  arbitrary  scale  to  Inches,  feet,  temperature,  or  other 
engineering  units. 

The  third  step  is  the  low  level  screening  of  the  data  value. 

Low  level  screening  assures  that  the  data  value  lies  within  a 
range  found  in  the  site  file  for  the  parameter  and  gage  loca¬ 
tion.  Low  level  screening  may  also  include  checks  on  the  per¬ 
missible  rate  of  change  of  the  variable  with  respect  to  time. 
Alarm  values  are  also  checked  for  exceedence.  Should  the  data 
value  exceed  the  alarm  value  for  the  site  and  parameter,  the 
Emergency  Alert  (All)  is  triggered. 

The  next  function  of  the  Data  Conversion  and  Screening  Program 
is  to  transform  observations  of  primary  hydrologic  data,  such 
as  stage  and  cumulative  precipitation,  into  more  useful  data, 
such  as  elevation,  flow,  storage,  and  incremental  precipita- 
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tion.  Procedures  and  parameters  for  performing  the  transforma¬ 
tion  are  stored  in  the  site  file  and  indexed  by  basin,  station, 
and  parameter  codes.  Severai  optional  transformation  proce¬ 
dures  are  available,  including  linear  and  non-linear  table  in¬ 
terpolation,  and  logarithmic  and  polynomial  functions. 

Data  are  then  written  to  a  sequential,  formatted  valid  data 
file.  The  file  is  then  used  for  database  update  and  may  be 
listed,  and  transmitted  to  other  locations.  The  files  of  valid 
data  are  limited  to  a  maximum  length.  This  allows  the  file  to 
be  closed  frequently  and  passed  on  to  the  database  entry  rou¬ 
tine  (D3). 

The  Data  Conversion  and  Screening  Program  is  initiated  by  calis 
from  the  communications  programs  through  the  Master  Control 
Program  and  by  user  commands.  The  program  runs  as  a  real-time 
program  at  priority  level  7.  Several  jobs  may  be  executed  si¬ 
multaneously  since  program  processing  is  de-coupled  from  com¬ 
munication  input  and  from  database  entry.  Access  to  the  shared 
Site  File  (A9),  Data  Entry  Log  (Ai2)  and  emergency  alert  memory 
flags  is  controlled  via  a  shared  status  table  in  memory. 

b .  2 . 1 .9  Site  File  Utility  (A10).  The  Site  File  Utility  pro¬ 
vides  the  capability  to  update  the  Site  File  (A9).  This  is 
necessary  because  the  site  file  is  a  direct  access  (random) 
file  which  provides  rapid  access  to  specific  file  elements  by 
the  Data  Conversion  and  Screening  Routine  (A8) ,  and  direct  ac¬ 
cess  fiLes  may  not  be  edited  with  a  text  editor.  Instead,  they 
require  a  separate  utility  routine  to  allow  for  entry  and  up¬ 
date  of  information. 

b. 2.1. 10  Emergency  Alert  Program  (All).  The  Emergency  Alert 
Program  is  responsible  for  the  automatic  notification  of  key 
personnel  of  emergency  conditions.  The  program  sends  an  alert 
based  on  critical  hydrologic  conditions  indicative  of  emergen¬ 
cies.  The  program  runs  as  a  real-time  program  at  priority  lev¬ 
el  6  and  is  initiated  by  the  Data  Conversion  and  Screening 
Program  (A8)  upon  the  detection  of  a  critical  observation.  The 
time  of  observation,  time  of  detection,  variable  value,  and 
basin,  station,  and  variable  identifiers  are  entered  into  a 
shared  memory  buffer.  The  information  is  also  written  to  an 
alert  log  file  (not  shown). 

A  threshold  may  be  set  as  to  the  number  of  sites  that  must  gen¬ 
erate  an  alert  before  the  Emergency  Alert  Program  is  Initiated. 
Once  the  program  lias  been  initiated,  it  is  locked  out  of  ini¬ 
tiation  for  a  specified  period  of  time  to  allow  a  response  from 
notified  personnel.  The  program  may  also  be  locked  out  by  user 
command.  If  an  attempt  is  made  by  the  Data  Conversion  and 
Screening  Program  to  Initiate  the  Emergency  Alert  Program  while 
that  program  is  locked  out,  alert  information  is  simply  entered 
into  the  memory  buffer  and  the  alert  files  until  the  program 


becomes  active  again.  At  that  time,  program  execution  is  ini¬ 
tiated  it  another  alert  message  is  present  in  the  memory  buf¬ 
fer.  The  buffer  may  be  cleared  by  the  user  to  prevent 
redundant  alerts.  An  alert  during  normal  duty  hours  will 
broadcast  a  message  to  water  control  users  terminals.  During 
off  hours,  an  auto-dialer  and  voice  synthesizer  may  be  used  to 
notify  on-call  personnel. 

b. 2.1. 11  Data  Entry  Log  (A12).  The  Data  Entry  Log  contains 
information  on  the  entry  of  data  from  various  input  sources. 
Entries  are  made  in  the  file  when  messages  are  received  by  the 
Data  Conversion  and  Screening  routine  that  cannot  be  processed 
or  that  contain  illegal  data.  This  log  will  contain  an  exact 
image  of  the  message  that  was  received.  This  will  allow  diag¬ 
nosis  of  the  error  problem  and  possible  reconstruction  of  the 
message.  In  addition  the  Data  Entry  Log  will  contain  diagnos¬ 
tic  messages  generated  by  the  satellite  downlink  station. 

Ttie  Data  Entry  Log  is  the  basis  for  a  daily  report  that  summar¬ 
izes  data  entry  performance. 

6.2.2  Data  Base  Utility  Group  (B).  The  Data  Base  Utility  Group 
pr  vldes  a  wide  range  of  important,  generalized  capabilities  in  ac¬ 
cessing,  tabulating,  plotting,  changing,  deleting,  adding,  copying, 
archiving,  transmitting  and  receiving  data  stored  in  the  data  base. 
Programs  in  this  group  operate  independently  of  each  other,  and 
provide  complementary  functions  which,  in  total,  are  essential  to  a 
flexible  and  efficient  approach  to  dacabase  management. 

b.2.2.1  Report  Generator  (Bl).  The  Report  Generator  routine 
is  the  primary  means  of  producing  end  user  products  (B8)  from 
the  system.  It  Is  used  to  retrieve  specific  data  from  the 
data  base,  to  sort,  compile,  format,  and  label  the  data  and 
produce  printed  and  CRT-displayed  reports.  Reports  may  be  held 
In  machine  form  and  copies  may  be  transmitted  to  other 
iocat ions. 

The  report  generator  is  usually  driven  by  a  file  (B2)  contain¬ 
ing  a  description  of  the  required  data  and  associated  format¬ 
ting  directives.  The  data  may  be  qualified  so  that  only  values 
that  meet  stipulated  criteria  are  included  In  the  report.  Sim¬ 
ple  computations  may  be  performed,  such  as  sums  of  report  col¬ 
umns,  and  report  data  may  be  sorted  before  being  output. 

Each  routine  or  standard  report  is  described  by  a  set  of  direc¬ 
tives,  allowing  easy  generation  of  periodic  updates.  Such  re¬ 
ports  may  be  initiated  on  demand  of  a  user  or  based  on  a 
pre-set  time  schedule. 

The  Report  Generator  may  also  be  used  to  generate  ad  hoc  or 
query  reports.  These  reports  are  usually  produced  on  a  one 
time  basis  only.  They  allow  a  manager  to  retrieve,  search, 
sort,  and  display  selected  Information  from  a  large  array  of 
Information  at  his  disposal. 
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All  data  available  to  the  Report  Generator  routine  must  be  de¬ 
fined  in  a  dictionary  which  describes  the  data  base.  The  user 
references  data  by  use  of  an  alphanumeric  label  associated  with 
the  data  item,  as  defined  In  the  data  dictionary. 

6.2.2. 2  database  Utility  Program  (B3).  The  Database  Utility 
provides  several  manipulation  and  housekeeping  functions  neces¬ 
sary  to  maintain  the  data  base  (D). 

A  sorted  inventory  of  the  data  base  may  be  listed  to  show  the 
stations,  parameters,  and  time  of  the  data  available.  The  in¬ 
ventory  provides  an  important  aid  for  the  database  manager  to 
copy,  archive,  purge  or  perform  other  such  operations  on  the 
data  base. 

The  archiving  function  provides  a  means  of  moving  older  portions 
of  the  data  from  on-line  disk  file  storage  to  magnetic  tape 
storage  (K9).  Tne  restore  function  performs  the  inverse  func¬ 
tion.  It  allows  an  older  portion  of  the  data  base  to  be  re¬ 
stored  to  the  disk  ftle.  When  restored,  older  data  may  be  used 
for  historical  comparisons,  for  re-evaluation,  model  testing,  or 
other  such  purposes.  The  purging  of  data  records  removes  the 
record  from  the  data  base.  This  allows  the  removal  of  records 
that  have  been  archived,  as  well  as  records  of  a  temporary  na¬ 
ture  that  are  no  longer  repaired. 

Records  may  also  be  copied  from  one  database  file  to  another. 
Copying  Is  one  means  of  creating  a  small  database  file  contain¬ 
ing  only  certain  records  of  the  master  data  base.  The  copy 
function  may  be  used  to  combine  data  records  in  two  database 
tiles  into  a  single  file. 

The  Database  Utility  also  provides  a  means  of  editing  data  in 
the  data  base.  When  editing,  the  data  may  be  displayed,  and 
changed.  Points  may  be  added  or  deleted  from  the  record.  The 
Database  Utility  Program  can  execute  as  either  an  interactive  or 
batch  control  point  job.  The  input  structure  consists  of  a  ser¬ 
ies  of  commands  with  related  parameters.  In  the  basic  interac¬ 
tive  session,  the  user  enters  a  command  and  Its  respective 
parameters  one  at  a  time.  In  the  batch  job,  a  series  of  com¬ 
mands  and  parameters  are  placed  in  a  file  and  the  file  provides 
command  directives  during  execution.  Simultaneous  executions  of 
the  program  are  permitted  when  operating  on  the  data  base,  since 
the  system  provides  for  multiple  access  to  the  data  base. 

u.2.2.3  Disjala_y  and  Graphical  Edit  Program  (BA).  The  Display 
and  Graphical  Edit  Program  provides  capah’ 1 1 t les  for  tabular  and 
graphical  display  of  information  in  the  lata  base.  Three  types 
of  data  displays  are  provided:  time  series  data,  paired  x-y  da¬ 
ta,  and  ID  x-y-z  data.  Each  type  of  data  may  be  tabulated  or 
plotted  graphically.  In  addition,  if  terminal  characteristics 
allow,  some  types  of  data  may  he  Input  or  edited  graphically. 
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Tabular  output  may  be  used  on  any  alphanumeric  output  device 
(e.g.,  Silent  700  hardcopy  terminal,  CRT  terminal,  line  print¬ 
er).  Tabular  output  Is  properly  paged  for  the  device  being 
used.  Graphical  output  may  be  used  on  black  and  white  graphics 
CRT  terminals  (e.g.,  Tektronix  4014,  4114),  color  graphics  CRT 
terminals  (i.e.,  Tektronix  4027,  4113),  or  hardcopy  pen  or  elec¬ 
trostatic  plotters  (e.g.,  Calcomp,  Versatech,  Zeta). 

Graphical  input  or  editing  may  be  used  on  any  terminal  with  an 
associated  digitizing  capability  (e.g.,  Summagraphics  digiti¬ 
zer,  Tektronix  tablet,  or  Altek  digitizer). 

Time  series  data  may  be  presented  in  tabular  form  with  appro¬ 
priate  time  labels  shown  as  well  as  station  and  parameter  lab¬ 
els.  Multiple  time  series  data  may  be  tabulated  on  the  same 
output  file  subject  to  the  width  limit  of  the  output  device. 

Time  series  data  may  be  plotted  with  up  to  six  separate  curves 
on  the  same  figure.  Up  to  two  types  of  parameters  may  be 
plotted,  allowing,  for  example,  both  stage  and  flow  to  appear 
on  the  same  figure.  Time  series  plots  may  have  an  optional 
grid,  be  windowed  to  show  data  more  clearly  and  be  plotted  to 
either  automatically  determined  or  user  specified  scales.  If 
graphics  input  capabilities  exist,  time  series  data  may  be  In¬ 
put  by  digitizing  data.  Similarly,  time  series  data  curves  may 
be  edited  to  remove  erroneous  points. 

Paired  x-y  data  may  be  presented  in  tabular  form  with  appropri¬ 
ate  labeLs  fully  Identifying  the  data.  If  multiple  dependent 
curves  exist  with  a  common  and  equal  Independent  variable,  mul¬ 
tiple  curves  may  be  tabulated  on  the  same  output  file  subject 
to  the  width  limit  of  the  output  device. 

I’aired  x-y  data  may  be  plotted.  If  multiple  dependent  curves 
exist  with  a  common  independent  variable,  multiple  curves  may 
appear  on  the  same  figure.  Up  to  two  different  dependent  vari¬ 
ables  may  be  displayed  using  separate  left  and  right  side  axis. 
Tf  graphics  Input  capabilities  exist,  paired  x-y  data  may  be 
input  or  edited. 

3D  x-y-z  data  may  be  presented  in  tabular  form  with  data  sorted 
by  x,  y,  or  z  value  or  combinations  thereof.  If  multiple  data 
sets  exist  with  two  common  and  equal  independent  variables, 
multiple  values  may  be  tabulated  up  to  the  width  limit  of  the 
output  device. 

Map  plots  of  3D  x-y-z  data  may  he  made,  where  the  z  variable  is 
shown  by  isoplots  (contours).  If  multiple  data  sets  exist  with 
two  common  independent  variables,  multiple  data  sets  may  appear 
on  the  same  figure.  if  the  z  variable  is  not  significant  such 
as  for  a  map  outline,  only  a  connected  polygon  would  be  shown. 
This  provides  the  capability  of  showing  the  map  outline  of  a 
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basin,  the  main  water  courses,  selected  man-made  features  and 
an  isohyetal  pattern  of  precipitation — all  on  a  composite  fig- 
aitf.  Where  color  graphics  CRT  terminals  exist,  isohyetal  pat¬ 
terns  may  be  color  shaded  to  emphasize  intense  precipitation 
a  teas . 

The  Display  and  Graphical  Edit  program  Is  normally  run  as  an 
interactive  program  at  priority  level  4.  It  is  also  possible 
to  execute  the  program  as  a  batch  job  where  directives  are  pre¬ 
stored  in  a  file  and  output  is  directed  to  a  plot  file. 

b.2. 2. 4  Mathpack  Program  (B5).  The  Mathpack  program  provides 
a  comprehensive  set  of  operations  for  the  statistical  analysis 
and  transformation  of  data  contained  in  the  data  base. 

a.  Several  statistical  analyses  may  be  performed  on  the 
data  in  the  data  base.  For  time  series  data  the  following 
may  be  determined: 

(1)  The  mean,  total,  standard  deviation  and  skewness 
ot  any  time  series  or  portion  thereof. 

(2)  The  minimum,  date/time  of  minimum,  maximum,  date/ 
time  of  maximum  of  the  complete  time  series  or  any  re¬ 
curring  portion  thereof.  Recurring  portions  of  time 
series  may  be,  tor  example,  each  decade,  each  year, 
each  of  the  four  quarters  of  a  year,  each  of  the  12 
months  of  a  year,  or  each  of  the  365  days  of  the  year. 

f  1 )  Dur.it  ion  curves,  distribution  function  (histo¬ 
gram',  or  : requeucy  curve  for  the  complete  or  any  re- 
!•  sir  r  i  :i,c  por  t  i  . >n  t  heroot  . 

(.4  i  o!  lit  statistics  (error  coefficients) 

In-:  . . .  '  w  '  (me  series. 

-i  >  t  i  i ;  ■  o  r  is- 1  a  t  ion  Coefficients  of  rime  series  . 

n.  Shv.t-i  1  !;  mst  ■•relations  may  he  performed  in  sequence 
•ei  it*  i  :  t  if  dtr  t  base.  A  new  time  series  wi  L 1  result 

»t  hi  ,  t  no:  .mat  inn  step.  At  each  step  the  new  time 
•.e  ii.-s  :m  !•■;  !  act  .ri  existing  time  series,  it  may  be 
save!  und-r  a  new  identifier,  or  it  may  be  held  for  use  in 
a  subsequent  step.  The  following  mani pul  at  ions  may  be 
per  !  ui  iii'ij  -  in  entire  time  series  or  portion  thereof: 

il  )  Add"  subtract  a  constant  to/from  each  value. 

C  i  Mui t i p 1 y , d i v ide  each  value  by  a  constant. 

(!)  Raise  each  value  to  a  power. 

(4)  Take  log  base  Id  of  each  value. 
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(5)  Take  antilog  base  10  of  each  value. 

(b)  Take  log  base  e  ot  each  value. 

(7)  Take  antilog  base  e  of  each  value. 

(8)  Accumulate  each  successive  value  (running  sum  or 
mass  curve). 

(0)  Difference  of  each  successive  value. 

(10)  Test  if  each  value  is  LT,  E<),  or  GE  a  constant 
and  if  so  set  value  to  another  constant. 

(11)  Adi/subtract  corresponding  values  of  2  time 
series. 

(L2)  Mul t iply/divide  corresponding  values  of  2  time 
series. 

(13)  Take  reciprocal  of  each  value. 

(la)  Replace  each  value  with  a  linear  interpolation 
from  a  tabular  function. 

T 1 > )  Change  time  interval. 

(16)  Determine  moving  average  for  specified  span  and 
skip. 

c.  Certain  specialized  functions  are  provided  that  would 
be  difficult  or  awkward  to  produce  with  the  general  trans¬ 
formation  capabilities.  These  include: 

(1)  Derivation  of  recurring  inflow  from  reservoir  pool 
elevation  and.  it  f  low  releases. 

(2)  Derivati  ot  reservoir  releases  from  pool  eleva- 
t  i  hi  and  ga  t  e  set  t  i  ngs  . 

Tne  output  front  the  muthpack  program  is  the  requested  manipula¬ 
tion  performed  on  the  data.  The  results  are  available  within 
the  data  base  as  well  as  in  printed  or  plotted  form  where  ap- 
p l i cab te . 


b.2.2.3  Data  Network  Link  (Bb).  The  Data  Network  Link  pro¬ 
gram  works  in  conjunction  with  the  computer's  resident  communi¬ 
cations  rout  :  nes  to  exchange  data  and  reports  with  other 
sites. 


When  sending  information  to  another  site  the  Data  Network  Link 
routine  accesses  the  designated  file,  adds  a  preamble  to  Lae 
file  indicating  its  destination  and  d i spot? it  ion  at  the  receiv¬ 
ing  site.  Tin:'  t  i  1  ■'  is  then  queued  for  transmission  to  the 
desired  site.  Transmission  may  occur  through  dedicated  syn¬ 
chronous  common i cat i on  lines,  auto  dial-up  synchronous  lines, 
or  manual  dial-up  synchronous  lines.  The  sending  site  must  act 
as  tie'  remote  job  entry  site  and  the  receiving  site  must  be  the 
hos  t  site. 


When  receiving  i  -it orin<i  t  ion  from  another  site,  the  received  file 
is  entered  info  the  host  system  input  queue.  From  the  input 
queue  tie  tile  i  processed  by  the  system  as  .3  batch  job.  The 
preamble  q  at .  ei:te  11  ;  ;  ,t  the  file  invoke  the  Data  Network  Link 
routine  whicii  directs  the  tile  to  its  final  disposition.  The 
i  of  .ini  u  ;  ■  1  auv  be  directed  to  a  specific  individual,  a  line 
printer,  m  ;  it  e  rue  t  i  ee  terminal,  or  into  the  receiving  loca¬ 
tion's  dot  1  bis,.-.  Confirmation  of  the  files  disposition  may  be 
ret  tuned  to  cite  sender  if  desired. 


o.l.  i  Anal  vs  is  Croup  (o'.  Hie  Analysis  Croup  comprises  a  set  of 
oompl oraent  arv  anuivtical  tools  for  the  analysis  of  current  hydrolog¬ 
ic  events,  p  r  :  tiia  t  i  y  to  provide  critical  information  for  immediate 
wa t e r-cun t m 1  decisions,  but  also  for:  postevent  analysis;  analyses 
of  historical  and  hypothetical  events,  with  alternative  operational 
scheme's;  and  training  of  water  control  personnel  with  simulated 
events.  The  analysis  t unctions  provided  bv  the  group  include: 

a.  High-level  data  screening  and  validation. 

b.  St  ream: low  1 orecust  model. 


c.  Operations  simulation  model. 

d.  Economic  analysis. 


e.  Extended  analysis. 

Several  Database  Utility  Group  ( B)  Programs  hav  important  roles  in 
analysis  in  entering  and  editing,  data,  tabulating  hydrographs,  plot¬ 
ting  hydrographs,  hyetographs ,  and  iso-hvetal  maps,  and  computing 
correlations  and  duration  curves  on  precipitat ion  and  flows. 


Programs  in  the  Analysis  Group  (Cl  use  t  v  Analysis  Database  Extract 
(Da),  a  subset  o:  the  main  data  base,  in  •. rd e  r  to  conserve  access 
time,  minimize  interference  with  other  programs,  and  simplify  data¬ 
base  management.  This  subset  contains  <-n  ly  the  data  records  needed 
for  the  analysis  of  the  user's  part,  i-  ,ti  has  i  n .  and  the  length  of 
each  time  series  record  is  restrict, si  to  that  needed  for  analysis. 
The  creation  of  tne  Analysts  Database  Extract  is  performed  bv  the 
Database  Utility  Program  (ill)  according  ' o  spec i f i oat  tons  contained 
in  an  input  macro  file  inn  shown  *  defining  the  selected  si  .lions, 
variables,  and  time  s.i.i".  i  hr  ext  raid  inn  is  performed  and  update! 
as  needed  daring  the  m.i )  vs  I  s ,  The  ropy  fuarti  >n  >1  the  Put  abas, 

’ '  t  i  1  i  t  v  1 1  so  sf  ,re  t  s  ■  ;  e,l  .  c :  ,  •  ••  ■ .  ■  s  r  1  t  :  into  the  mat’  1  . ,  t  < 
base  anytime  dc  •  ,  ■  •  1  . ;  1  c  i  .  ,  1  i  v  s  i  s  .  l'it  isunliv  1 : 

Tlie  Ana  1  vs  is  is 
programs  , t  o 

UU  t  e  ’ll  [.-it 


■  i 


AD- A 1 34  359 


WATER  CONTROLDATA  Sf STEM  SOFTWARE  MANUAL  I U  I  CORPS  OF 
ENGINEERS  DALLAS  TX  SOUTHWESTERN  OIV  FEB  83 


A3 


UNCLASSIFIED 


F/G  13/2 


NL 


MICROCOPY  RESOLUTION  TEST  CHART 

national  bureau  Of  stanoaads  -  >»6S  - A 


(5)  Take  antilog  base  10  of  each  value. 

(6)  Take  log  base  e  of  each  value. 

(7)  Take  anti  Log  base  e  of  each  value. 

(8)  Accumulate  each  successive  value  (running  stun  or 
mass  curve). 

(9)  Difference  of  each  successive  value. 

(10)  Test  if  each  value  is  LT,  EQ,  or  GE  a  constant 
and  If  so  set  value  to  another  constant. 

(11)  Add/subtract  corresponding  values  of  2  time 
series. 

(L2)  Multiply/divide  corresponding  values  of  2  time 
series. 

(13)  Take  reciprocal  of  each  value. 

(14)  Replace  each  value  with  a  linear  interpolation 
from  a  tabular  function. 

(15)  Change  time  interval. 

(16)  Determine  moving  average  for  specified  span  and 
skip. 

c.  Certain  specialized  functions  are  provided  that  would 
be  difficult  or  awkward  to  produce  with  the  general  trans¬ 
formation  capabilities.  These  include: 

(1)  Derivation  of  recurring  inf Low  from  reservoir  pool 
elevation  and  outflow  releases. 

(2)  Derivation  of  reservoir  releases  from  pool  eleva¬ 
tion  and  gate  settings. 

The  output  from  the  mathpack  program  is  the  requested  manipula¬ 
tion  performed  on  the  data.  The  results  are  available  within 
the  data  base  as  well  as  in  printed  or  pLotted  form  where  ap¬ 
plicable. 

6. 2. 2. 5  Data  Network  Link  (B6).  The  Data  Network  Link  pro¬ 
gram  works  in  co-junction  with  the  computer's  resident  communi¬ 
cations  routines  to  exchange  data  and  reports  with  other 
sites. 

When  sending  information  to  another  site  the  Data  Network  Link 
routine  accesses  the  designated  file,  adds  a  preamble  to  the 
file  indicating  its  destination  and  disposition  at  the  receiv¬ 
ing  site.  The  file  is  then  queued  for  transmission  to  the 
desired  site.  Transmission  may  occur  through  dedicated  syn¬ 
chronous  communication  lines,  auto  dial-up  synchronous  lines, 
or  manual  dial-up  synchronous  lines.  The  sending  site  must  act 
as  the  remote  job  entry  site  and  the  receiving  site  must  be  the 
host  site. 
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When  receiving  information  from  another  site,  the  received  file 
is  entered  into  the  host  system  input  queue.  From  the  input 
queue  the  file  is  processed  by  the  system  as  a  batch  job.  The 
preamble  statements  in  the  file  invoke  the  Data  Network  Link 
routine  which  directs  the  file  to  its  final  disposition.  The 
information  may  be  directed  to  a  specific  individual,  a  line 
printer,  an  interactive  terminal,  or  into  the  receiving  loca¬ 
tion's  data  base.  Confirmation  of  the  files  disposition  may  be 
returned  to  the  sender  if  desired. 

6.2.3  Analysis  Group  (C).  The  Analysis  Group  comprises  a  set  of 
complementary  analytical  tools  for  the  analysis  of  current  hydrolog¬ 
ic  events,  primarily  to  provide  critical  information  for  immediate 
water-control  decisions,  but  also  for:  postevent  analysis;  analyses 
of  historical  and  hypothetical  events,  with  alternative  operational 
schemes;  and  training  of  water  control  personnel  with  simulated 
events.  The  analysis  functions  provided  by  the  group  include: 

a.  High-level  data  screening  and  validation. 

b.  Streamflow  forecast  model. 

c.  Operations  simulation  model. 

d.  Economic  analysis. 

e.  Extended  analysis. 

Several  Database  Utility  Group  (B)  Programs  have  important  roles  in 
analysis  in  entering  and  editing  data,  tabulating  hydrographs,  plot¬ 
ting  hydrographs,  hyetographs,  and  iso-hyetal  maps,  and  computing 
correlations  and  duration  curves  on  precipitation  and  flows. 

Programs  in  the  Analysis  Group  (C)  use  the  Analysis  Database  Extract 
(D4),  a  subset  of  the  main  data  base,  in  order  to  conserve  access 
time,  minimize  interference  with  other  programs,  and  simplify  data¬ 
base  management.  This  subset  contains  only  the  data  records  needed 
for  the  analysis  of  the  user's  particular  basin,  and  the  length  of 
each  time  series  record  is  restricted  to  that  needed  for  analysis. 
The  creation  of  the  Analysis  Database  Extract  is  performed  by  the 
Database  Utility  Program  (B3)  according  to  specifications  contained 
in  an  input  macro  file  (not  shown)  defining  the  selected  stations, 
variables,  and  time  span.  The  extraction  is  performed  and  updated 
as  needed  during  the  analysis.  The  copy  function  of  the  Database 
Utility  a) so  stores  selected  analysis  results  into  the  main  data 
base  anytime  desired  during  the  analysis,  but  usually  at  the  end. 

The  Analysis  Group  Programs  and  applicable  Database  Utility  Group 
programs  are  used  by  project  managers  and  their  assistants  to  eval¬ 
uate  current  hydrologic  and  raeteorologic  conditions,  make  forecasts 
of  future  hydrologic  conditions  based  on  alternative  projections  of 
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current  conditions  and  assumptions  about  future  meteorological 
events,  and  to  test  alternative  operation  schemes  under  future 
scenarios  in  order  to  help  formulate  appropriate  operational 
actions  for  current  and  future  times. 

In  most  applications,  the  Data  Analysis  Program  (Cl)  is  used  first 
to  establish  the  most  likely,  logically  consistent  set  of  data  pos¬ 
sible  on  which  to  base  further  analysis.  Project  management  per¬ 
sonnel  use  the  Data  Analysis  Program  to  examine  the  validity  of 
observed  field  data  at  individual  locations  in  context  with  other, 
nearby  stations.  This  is  accomplished  in  conjunction  with  the  Dis¬ 
play  and  Graphical  Edit  Program  (B4)  to  correlate  mass  curves  of 
precipitation  and  runoff,  to  map  precipitation  patterns,  and  to  ed¬ 
it  erroneous  data.  In  addition,  the  Data  Analysis  program  esti¬ 
mates  missing  precipitation  data,  computes  basin  mean  precipitation 
by  period  for  use  by  the  Streamflow  Forecast  Model,  and  allows  di¬ 
rect  user  input  of  alternative  future  basin  mean  precipitation 
amounts  for  forecasting  purposes.  Adjustments  to  observed  data  and 
basin  average  precipitation  are  stored  in  the  Analysis  Database  Ex¬ 
tract. 

Once  the  basic  analysis  data  have  been  refined,  the  Streamflow 
Forecast  Model  (C2)  is  used  to  estimate  future  streamflows  at  key 
operation  points.  Future  streamflows  are  the  result  of  precipita¬ 
tion  up  to  the  current  time  together  with  future  precipitation 
amounts  and  losses.  Several  alternative  future  scenarios  with  dif¬ 
ferent  precipitation  amounts  and  ground  conditions  may  be  evaluated 
for  comparing  several  alternatives.  Projections  of  streamflow  for 
each  of  the  alternative  scenarios  are  stored  in  the  Analysis  Data¬ 
base  Extract. 

The  Operations  Model  (C3)  simulates  the  effects  of  the  operation  of 
water  control  facilities  such  as  dams,  hydroelectric  powerplants, 
and  navigation  locks  on  future  hydrologic  conditions.  Alternative 
operational  decision  schemes  are  built  into  the  model  program  and 
are  selected  by  the  user  by  operating  interactively  on  the  Basin 
Model  File  (C9)  with  the  Operations  Model  Pre-processor  (C8).  The 
Basin  Model  File  also  contains  information  about  streamflow  rout¬ 
ings  and  relevant  operating  characteristics  of  water  control  facil¬ 
ities.  Hydrologic  inputs  at  key  control  points  and  water  control 
facilities  are  retrieved  from  the  Analysis  Database  extract  (D4) 
and  results  of  alternative  operation  schemes  are  stored  in  it. 

The  results  of  either  forecasting  or  operations  simulation  may  be 
tabulated  or  plotted  by  the  Display  and  Graphical  Edit  program 
(B4 ) .  Statistics  may  also  be  computed  on  the  results  and  they  may 
also  be  transformed  by  the  Mathpack  program  (B5). 
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Benefits  and  losses  (damages)  occurring  during  one  or  several  peri¬ 
ods  of  time  are  computed  with  the  Economic  Analysis  program  (C4). 
Benefits  and  losses  may  be  specified  as  functional  dependents  of 
hydrologic  and  hydraulic  variables  available  in  the  Analysis  Data¬ 
base  Extract  (D4),  including  flow,  stage,  and  energy  generated. 

The  functional  relationships  defining,  for  instance,  damages  as  a 
function  of  flow  are  also  contained  within  the  Analysis  Database 
Extract.  The  computations  of  specific  economic  data  are  controlled 
primarily  by  means  of  interactive  user  directives. 

Extended  analysis  (C5)  capabilities  may  include  reservoir  water 
supply  storage  accounting  for  individual  users,  and  forecasting  and 
operations  simulation  models  of  coastal  surge,  tidal  velocities, 
sediment  transport,  and  water  quality.  (The  inclusion  of  any  of 
these  analysis  tools  could  involve  additions  or  modification  to  the 
Data  Analysis  Program  as  well.) 

In  general,  programs  in  the  Analysis  Group  and  Database  Utility 
Group  are  run  interactively  to  provide  the  flexibility  and  control 
desirable  in  the  analysis  process.  Convenience  and  additional 
flexibility  are  provided  with  the  integration  of  the  Interactive 
Input  Control  System,  which  is  described  in  paragraph  6. 3. 1.2. 

The  Streamflow  Forecast  and  Operations  Models  must  have  provisions 
for  interactive  use,  and  user  interrupt  at  various  points  as  de¬ 
scribed  in  paragraphs  5.3.3. 1  and  5. 3. 3. 2. 

6.2.3. 1  Data  Analysis  Program  (Cl).  Field  observations  of  hy¬ 
drologic  and  meteorologic  time-series  data  stored  in  the  data 
base  by  the  Acquisition  Group  have  been  screened  for  fixed 
ranges  of  reasonable  values  and  rates  of  change  of  values. 
However,  the  data  need  further  screening  before  they  can  be 
used  with  confidence  in  the  Analysis  Process.  Missing  data 
•  must  be  filled  in,  and  data  from  individual  gages  must  be  exam¬ 

ined  for  validity  in  the  context  of  the  pattern  shown  by  all 
other  gages.  This  secondary  screening  involves  a  high  degree 
of  user  interpretation  and  interaction.  The  Data  Analysis  Pro¬ 
gram  (Cl)  in  conjunction  with  the  Display  and  Graphical  Edit 
Program  (B4)  facilitates  this  secondary  screening  and  provides 
several  basic  technical  tools  to  assist  the  user.  In  addition, 
the  Data  Analysis  Program  provides  means  of  saving  the  results 
of  the  secondary  screening  in  a  suitable  format  in  the  Analysis 
Database  Extract  (D4)  for  subsequent  use  by  other  Analysis 
Group  programs. 

Many  of  the  capabilities  provided  by  the  Data  Analysis  program 
are  oriented  to  the  screening  of  meteorological  data  and  deri¬ 
vation  of  areal  patterns  such  as  basin  precipitation  amounts 
because  of  the  dependence  of  hydrologic  events  on  meteorologic¬ 
al  ones.  In  the  simplest  analysis,  mass  curves  of  precipita¬ 
tion  at  sev  ral  stations  may  be  plotted  simultaneously  and 
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edited  by  plotted  simultaneously  and  edited  by  graphical  means, 
such  as  a  light  pen  or  graphics  tablet  with  the  Display  and 
Graphical  Edit  Program  (B4).  At  a  somewhat  higher  level  of 
sophistication,  precipitation  at  a  specific  station  may  be  de¬ 
rived  or  compared  with  surrounding  stations  by  means  of  several 
conventional  methodologies,  such  as  weightings  based  on  long¬ 
term  averages,  for  instance,  or  regional  correlation  specific  to 
the  current  event.  At  the  highest  level  of  sophistication,  iso- 
hyetal  patterns  will  be  mapped  by  the  Data  Analysis  Program  and 
the  map  displayed  and  graphically  edited  by  use  of  the  Display 
and  Graphical  Edit  Program.  Furthermore,  satellite  and  radar 
imagery  may  be  mapped  in  the  same  format  for  comparison  and  reg¬ 
istration  of  the  imagery.  Finally,  when  a  reasonably  consistent 
precipitation  distribution  is  accepted,  the  Data  Analysis  Pro¬ 
gram  computes  basin  average  precipitation  from  ground  data  and 
imagery  and  stores  the  results  in  the  Analysis  Database  Extract 
for  use  by  the  Streamflow  Forecasting  Model  (C2). 

As  with  precipitation  data,  the  basic  technique  for  secondary 
screening  of  streamflow  data  is  comparison  by  plotting  with 
graphical  editing  using  the  Display  and  Graphical  Edit  Program. 
At  a  higher  level  of  refinement,  runoff  volumes  per  square  mile 
may  be  computed  for  the  current  event  by  the  Data  Analysis  pro¬ 
gram  and  compared  with  other  streamflow  stations,  based  on  long¬ 
term  averages,  correlations,  or  precipitation  patterns  to 
evaluate  continuity  and  to  fill  in  missing  values.  Adjusted 
streamflow  data  are  stored  in  the  Analysis  Database  Extract  for 
further  analysis. 

Basic  field  data  for  analysis  are  retrieved  by  the  Data  Analy¬ 
sis  Program  from  the  Analysis  Database  Extract,  including  obser¬ 
vations  of  ground  station  precipitation  amounts,  satellite 
imagery  of  precipitation  patterns,  and  streamflow.  Other  para¬ 
meters,  such  as  correlation  coefficients,  NAP  values,  and  drain¬ 
age  areas  may  also  be  retrieved  from  the  extract  or  may  be 
entered  interactively  or  saved  in  interactive  user  macros.  (See 
paragraph  6.3. 1.2  for  a  description  of  interactive  user  macros 
and  their  capabilities.) 

6 . 2 . 3 . 2  Streamflow  Forecast  Model  (C2)  and  Pre-Processor  (C6). 
An  estimate  of  future  runoff  is  essential  in  making  water  con¬ 
trol  decisions  and  plans  for  operations.  The  role  of  the 
Streamflow  Forecast  Model  is  to  estimate  future  runoff  at  key 
locations  to  provide  a  basis  for  analysis  of  alternatives. 

Future  runoff  is  a  function  of  both  past  and  future  precipita¬ 
tion,  soil  moisture  content,  and  the  physical  characteristics  of 
the  drainage  basin.  Data  on  past  precipitation  are  retrieved 
from  the  Analysis  Database  Extract  (D4)  as  sub-basin  averages; 
the  data  have  been  screened  and  averaged  using  the  Data  Analysis 
(Cl)  and  Display  and  Graphical  Edit  Programs  (B4).  Sub-basin 
divisions  are  consistent  with  streamflow  gaging  station  loca¬ 
tions. 


Future  precipitation  is  also  retrieved  from  the  Data  Analysis  Ex¬ 
tract  as  basin  averages.  Several  alternative  future  precipitation 
patterns  and  amounts  may  be  investigated,  and  all  will  contain  the 
same  record  for  times  prior  to  the  forecast  time. 

The  physical  characteristics  of  the  basin  are  described  by  data  re¬ 
trieved  from  the  Basin  Model  File  (C7),  parts  of  which,  are  period¬ 
ically  extracted  from  the  main  data  base  as  required  by  significant 
changes  in  the  data.  The  file  includes  information  on  drainage 
areas,  the  stream  network  linkage  and  routing  coefficients,  unit 
hydrographs,  loss  rate  function  par^-^ers,  and  parameters  control¬ 
ling  some  of  the  computational  proceed.  ;s  and  processing  logic  in¬ 
corporated  in  the  forecasting  program. 

In  order  to  accurately  forecast  future  hydrologic  conditions,  it  is 
necessary  to  accurately  assess  the  state  of  the  basin  at  the  fore¬ 
cast  time,  and  it  is  essential  that  forecasted  streamflows  corre¬ 
spond  with  actual,  observed  flows  at  the  beginning  of  the  forecast. 
These  needs  are  met  to  the  extent  possible  by  internally  adjusting 
basin  response  variables  with  precipitation  observed  prior  to  the 
forecast  time  match  observed  streamflows  during  that  period  as 
nearly  as  possible.  Observed  streamflows  are  retrieved  from  the 
Analysis  Database  Extract.  Where  observed  streamflows  at  a  partic¬ 
ular  location  include  runoff  from  areas  above  an  upstream  gage,  ob¬ 
served  flows  at  the  upstream  gage  are  routed  to  the  location  and 
subtracted  to  compute  the  runoff  for  the  intervening  sub-basin  cor¬ 
responding  to  the  gage  at  that  location. 

The  Streamflow  Forecast  Model  normally  runs  as  a  batch  job.  How¬ 
ever,  it  should  be  designed  to  allow  interactive  interrupt  at  vari¬ 
ous  points  by  the  user.  The  user  may  need  to  observe  results  at 
various  points  in  the  forecast  and  make  changes  to  the  data  prior 
to  completion  of  the  entire  forecast.  This  user  requirement  is  de¬ 
scribed  in  Chapter  5. 

The  Streamflow  Forecast  Pre-processor  (C)  is  the  interactive  pro¬ 
gram  used  to  control  the  initiation  of  the  Streamflow  Forecast  Mod¬ 
el  and  to  make  modifications  to  the  Basin  Model  File  (C7)  necessary 
in  day-to-day  use.  The  pre-processor  reads  the  Basin  Model  File, 
modifies  its  contents,  and  writes  a  modified,  temporary  version  of 
the  model  file  for  immediate  use  by  the  model  program.  Modifica¬ 
tions  to  the  model  parameters  involving  the  internal  accounting  of 
time  are  made  automatically  by  the  program  based  on  the  forecast 
time.  Other  changes  may  be  made  by  interactive  user  directives. 

The  pre-processor  creates  a  job  control  file  necessary  to  run  the 
forecast  model.  When  all  modifications  have  been  made  to  the  model 
file,  the  job  control  file  is  placed  in  the  batch  job  queue  to  ini¬ 
tiate  execution  of  the  forecast  model  program. 

6. 2. 3.3  Operations  Model  (C3)  and  Pre-Processor  (C8).  The  role  of 
the  Operations  Model  (C3)  in  water  control  is  to  evaluate  the  ef¬ 
fects  of  water  control  strategies  and  alternative  water  control 
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decisions  on  the  hydrology  and  hydraulics  of  a  particular  region 
and  period  of  time  given  the  independent,  uncontrolled  hydrologic 
events  occurring  during  that  time.  The  effects  of  control  actions 
are  evaluated  through  mathematical  simulations  of  hydrologic  and 
hydraulic  processes  coupled  with  internal  logic  which  parallels  op¬ 
erations  rules  and  decisions. 

Operations  objectives,  strategies  and  decisions  may  be  based 
directly  on  many  combinations  of  variables,  including  reservoir 
storages,  stages  or  flows  at  critical  locations,  power  genera¬ 
tion,  water  demand,  and  related  economic  variables  such  as  rev¬ 
enues  and  costs.  In  addition,  decisions  are  often  influenced 
by  unique  external  circumstances,  such  as  recreation  needs, 
construction  activities  and  levee  failures. 

In  most  cases,  operations  decisions  are  indicated  by  a  set  of 
decision  rules  developed  in  accordance  with  overall  strategies 
and  objectives.  These  decision  rules  are  incorporated  in  the 
logic  of  the  Operations  Model  program.  Moreover,  alternative 
decision  rules  corresponding  to  different  strategies  and  objec¬ 
tives  are  incorporated  as  well  to  facilitate  rapid  and  effi¬ 
cient  comparisons  and  contrasts  among  the  different  strategies 
and  objectives.  For  example,  the  project  manager  might  wish  to 
compare  a  simulated  operation  with  power  production  as  a  prior¬ 
ity  to  one  with  a  priority  of  meeting  water  supply  demand.  The 
selection  of  alternative  decision  rules  is  accomplished  by 
changing  key  indicator  variables  in  the  program  input. 

When  extraordinary,  external  circumstances  Influence  operations 
decisions,  unique  control  decisions  may  be  tested  by  simply 
specifying  the  dependent  decision  variable  rather  than  allowing 
the  variable  to  be  determined  from  an  internalized  set  of  deci¬ 
sion  rules.  For  example,  a  project  manager  faced  with  emergen¬ 
cy  construction  downstream  from  a  reservoir  would  like  to 
simulate  the  effects  of  a  specific  release  schedule  on  the  res¬ 
ervoir  pool  and  on  downstream  flows.  Furthermore,  the  control 
actions  indicated  by  conforming  with  decision  rules,  but  gener¬ 
ally  are  not  consistent  with  practical  operation.  For 
instance,  reservoir  outflows  simulated  in  accordance  with  a  de¬ 
cision  rule  are  computed  to  fractions  of  cubic  feet  per  second 
and  might  fluctuate  from  period  to  period,  while  in  practice, 
releases  are  specified  to  the  nearest  hundred  cubic  feet  per 
second,  and  are  held  as  constant  as  possible.  The  ability  to 
specify  releases  allows  the  project  manager  to  simulate  the  re¬ 
sults  of  the  final  operation  plan  which  is  based  on,  but  not 
exactly  equal  to,  the  plan  indicated  by  pure  conformance  with 
decision  rules. 

Independent,  time-variable  decision  variables,  such  as  reser¬ 
voir  Inflows  and  uncontrolled  flows  at  downstream  control 
points  are  retrieved  from  the  Analysis  Database  Extract  where 
they  were  stored  by  the  Streamflow  Forecast  Model.  Several 
different  future  scenarios  may  be  represented  by  data  in  the 
extract  file. 
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Fixed  operation  decision  variables,  such  as  channel  capacity, 
are  contained  in  the  Basin  Model  File  (C9),  as  are  project  and 
basin  description  variables,  such  as  reservoir  storage- 
elevation  tables,  streamflow  routing  parameters,  and  decision 
rule  curves.  Project  description  data  are  extracted  from  the 
master  data  base  from  time  to  time  as  required  to  maintain  cur¬ 
rent  information. 

Data  are  retrieved  from  the  Basin  File  (C9)  by  the  Operations 
Model  Preprocessor  (C8).  The  pre-processor  enables  the  project 
manager  to  make  temporary  changes  to  key  operation  variables 
interactively,  as  desired.  A  working  input  file  to  the  Opera¬ 
tions  model  is  created  incorporating  the  desired  changes  to  the 
Basin  Model  File. 

The  Operations  Model  shall  be  designed  to  allow  interactive 
use.  As  described  in  Chapter  V  the  user  may  have  a  need  to  ob¬ 
serve  the  results  at  various  points  and  stop  the  model  and  make 
changes . 


6. 2. 3. A  Economic  Analysis  Program  (C4).  The  Economic  Analysis 
Program  has  two  basic  purposes.  First,  in  developing  immediate 
water  control  decisions,  it  is  often  important  to  assess  the 
economic  consequences  of  alternatives  for  current  real-time  op¬ 
erations.  The  Economic  Analysis  Program  is  used  for  this  pur¬ 
pose  to  estimate  economic  costs  and  benefits  from  projected 
hydrologic  data  stored  in  the  Analysis  Database  Extract. 

Secondly,  it  is  standard  and  required  practice  in  tracking  the 
performance  of  water  control  projects  to  compute  economic  bene¬ 
fits  following  individual  flood  events.  The  Economic  Analysis 
Program  shall  compute  benefits  for  any  number  of  events,  but 
project  benefits  are  normally  computed  at  the  end  of  each  year 
and  stored  in  the  main  data  base  for  future  reference. 

The  Economic  Analysis  Program  is  an  interactive  program.  It  is 
used  in  close  conjunction  with  the  Mathpack  Program  (B5).  The 
latter  computes  multiple  durations  of  hydrologic  data,  finds 
annual  maxima  and  minima,  and  assigns  probabilities  to  events 
by  computing  annual  frequency  statistics  and  evaluating  the 
probabilities  of  individual  events  in  terms  of  the  statistics. 
Since  the  two  operate  closely  together,  the  Mathpack  Program 
may  be  called  from  within  the  Economic  Analysis  Program,  and 
the  two  share  common  working  database  files  for  more  efficient 
data  transfer  between  them. 

The  Economic  Analysis  Program  can  evaluate  costs  and  income  for 
several  categories,  each  for  several  durations  of  time-series 
data.  Cose  and  income  functions  are  stored  in  tables  in  the 
main  data  base  and  are  also  contained  in  the  Analysis  Database 
Ext  ract . 
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6. 2. 3. 5  Extended  Analysis  (C5).  The  Analysis  Group  (C)  pro¬ 
grams  described  in  the  immediately  preceding  paragraphs  are 
ones  that  are  essential  in  meeting  the  general  basic  needs  of 
water  control.  However,  basic  water  control  needs  in  specific 
environments  differ  significantly.  In  offices  with  contractual 
water  supply  and  power  responsibilities,  water  supply  storage 
demand  allocation  for  individual  users  and  power  accounting 
programs  are  necessary.  In  offices  with  responsibility  in 
coastal  areas,  coastal  surge  and  tidal  velocity  models  may  be 
considered  equally  essential.  Furthermore,  certain  specialized 
analysis  functions  in  nearly  all  offices  are  very  important  if 
not  essential.  Related  analysis  programs  include  water  quality 
models  for  lakes,  rivers  and  bays,  water  surface  profile  mod¬ 
els,  and  sediment  transport  models. 

These  programs  which  extend  analysis  capabilities  share  charac¬ 
teristics  with  the  basic  analysis  programs  described  in  detail 
above.  Individual  programs  perform  unique  functions  or  a 
unique  group  of  closely  related  functions  that  are  distinctly 
independent,  both  structurally  and  functionally  from  other  pro¬ 
grams.  The  bulk  of  their  input  data  consists  of  time  series 
hydrologic,  hydraulic,  and  meteorologic  data  and  basin-related 
data  which  are  maintained  in  the  main  data  base,  but  directly 
accessed  from  an  extract  of  the  main  data  base.  The  programs 
run  interactively  except  when  they  perform  complex  repetitive 
computations,  in  which  case  they  run  as  batch  jobs  and  utilize 
an  interactive  pre-processor  for  input  of  key  variables  and  for 
control.  Some  of  these  programs  may  reside  on  large  main-frame 
processors  due  to  their  size.  The  WCDS  system  would  package 
the  input  data  and  submit  them  to  the  large  system  for  process¬ 
ing.  The  results  would  then  be  retrieved  back  to  the  WCDS  for 
display. 

The  power  program  computes  allocations  of  power  demands  for 
each  reservoir  based  on  contractual  commitments  and  long-term 
flow  forecasts.  The  input  to  the  program  mainly  includes  fore¬ 
casted  reservoir  inflows,  outflows,  and  storage.  Program  out¬ 
put  contains  power  generation  schedules  for  each  project. 

Coastal  surge  programs  combine  analysis  of  meteorological  and 
tidal  data  to  forecast  coastal  surge  resulting  from  storms. 

Tidal  velocity  models  provide  the  capability  to  analyze  and 
forecast  flows,  velocities  and  stages  within  an  estuary  based 
on  the  tidal  fluctuations  at  the  estuary  entrance,  freshwater 
inflows  to  the  estuary,  and  physical  characteristics  of  the  es¬ 
tuary  and  connecting  channels. 
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Water  quality  models  of  lak.es,  rivers  and  bays  superimpose  mod¬ 
els  of  physical,  chemical,  and  biological  processes  which  de¬ 
termine  water  quality  upon  the  Important  transport  processes 
operating  In  each  of  the  different  water  environments.  Water 
quality  models  require  a  considerable  variety  and  volume  of 
time-dependent  Input  data  in  addition  to  flows  and  storage,  in¬ 
cluding  the  quality  of  inflowing  waters  in  terms  of  several 
variables,  such  as  temperature,  dissolved  oxygen,  and  concen¬ 
trations  of  chemical  nutrients  and  organic  matter,  and  meteoro¬ 
logical  data  such  as  air  temperature,  wind  velocity,  and  cloud 
cover. 

Water  surface  profile  and  sediment  transport  models  account  for 
the  geometry  of  streambeds  and  its  effect  on  hydraulics  in  pre¬ 
dicting  stages  and  sediment  scour  and  deposition.  Water 
surface  profile  and  sediment  transport  models  require  a  sub¬ 
stantial  volume  of  data  describing  the  geometry  of  stream- 
courses,  mainly  cross-section  and  profile  data,  and  relatively 
little  data  on  flows.  Sediment  transport  models  additionally 
require  data  on  quantities,  composition,  and  distribution  of 
sediment  in  streambeds. 

6.3  Support  Software.  Water  control  system  Support  Software  consists 
of  programs,  subroutine  libraries,  and  computer  job  control  language  - 
(JCL.)  based  procedures  (macros  and  procedure  files)  that  integrate  the 
basic  discrete  applications  -  related  components  into  a  coherent  system 
and  that  provide  supplementary  capabilities  in  water  control  manage¬ 
ment.  See  Figure  6-2. 

a.  The  Control  routines  operationally  integrate  application  pro¬ 
grams  by  controlling  sequences  and  schedules  of  process  (program) 
initiation. 

b.  The  Records  Group  implement  record-keeping  as  well  as  analysis 
of  system  operations  for  user  information  and  control  feedback. 

c.  The  database  routines  are  implemented  in  individual  application 
routines  as  needed  to  provide  access  to  required  data. 

d.  Communications  among  users  and  water  control  managers  at  dif¬ 
ferent  work  stations  and  different  sites  is  aided  by  a  collection 
of  host  computer  capabilities  and  special  programs. 

e.  Training  of  water  control  management  personnel  is  aided  by 
self-document Ing ,  self-guiding  interactive  programs  and  documenta¬ 
tion  stored  in  system  files.  In  addition,  water  control  system  op¬ 
erations  may  be  simulated  through  use  of  the  application  programs 
with  actual  data,  including,  for  example,  large  historic  flow 
events . 
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Support  Software  makes  appropriate  use  of  host  computer-based  capa¬ 
bilities  in  order  to  achieve  savings  in  development,  efficiency  in 
operation,  simplicity,  and  savings  in  storage  requirements.  At  the 
same  time,  system  features  are  made  invisible  to  the  user  as  much 
as  possible;  a  uniform  command  syntax  and  style  are  a  primary  ob¬ 
jective  of  system  design. 

6.3.1  Control  Routines  (R).  The  Control  routines  provide  the 
software  necessary  to  operationally  integrate  water  control  system 
components,  both  applications  and  support  programs,  to  function  as 
a  coherent,  coordinated  system.  In  general,  program  executions  may 
be  initiated  automatically  by  the  system  or  upon  user  command. 

Automatic  program  initiations  may  be  set  to  occur  at  a  given  fre¬ 
quency,  every  10  minutes  for  example,  on  a  schedule  at  specific 
times,  or  as  the  result  of  events,  such  as  the  end  of  execution  of 
another  program.  All  of  the  automatic  initiation  schemes  may  be 
conveniently  changed  by  the  user  as  desired. 

User  control  of  program  initiations  and  control  during  interactive 
executions  are  enhanced  through  use  of  special  function  keys,  input 
macros,  and  graphics  tablet  input  together  with  an  interactive,  ex¬ 
ecutive  level  program  which  controls  the  initiation  of  real-time, 
batch  and  interactive  programs.  Function  keys,  input  macros  and 
graphics  tablet  input  are  defined  with  files,  which  are  easily 
changed  by  the  user,  thus  avoiding  the  need  for  program  changes. 

Finally,  job  control  language  (JCL)  procedures  and  macros  are  pro¬ 
vided  to  enable  the  implementation  of  water  control  software  on 
multiple  host  computers. 

6. 3. 1.1  Master  Control  Program  (Rl).  The  Master  Control  Pro¬ 
gram  is  the  primary  control  over  all  automatic  system  proces¬ 
ses.  This  program  is  used  by  the  system  manager  to  control  all 
clock  driven  system  real-time  programs.  With  it,  the  manager 
can  initiate  not  only  real  time  programs,  but  can  also  stop  and 
suspend  them  and  query  or  change  their  status.  This  program 
provides  automatic  Initiation  of  water  control  system  processes 
at  regular  Intervals,  irregular  intervals  at  specific  schedules 
times,  or  in  response  to  calls  from  other  processes.  Any  real¬ 
time  or  batch  control  point  program  may  be  initiated  in  this 
manner.  In  addition,  processing  priorities  may  be  assigned 
among  programs  running  under  each  of  these  categories.  A  sche¬ 
matic  of  the  Master  Control  Program’s  operating  environment  is 
presented  in  Figure  6-3. 

The  Master  Control  Program  also  provides  the  automatic  initia¬ 
tion  of  other  processes.  Three  time  initiated  schemes  are 
available : 
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a.  Recurring  at  specified  times — processors  that  must  be 
initiated  at  specified  times  each  and  every  hour  are  de¬ 
fined  in  the  recurring  hourly  schedule.  The  time,  mea¬ 
sured  from  the  beginning  of  the  hour  in  minutes,  indicates 
when  the  particular  program  should  be  initiated  each  hour. 
Analogous  to  recurring  hourly  schedules  are  recurring 
daily,  weekly,  monthly  and  yearly  schedules.  This  allows 
certain  products  to  be  run  each  hour,  others  each  day,  and 
others  only  certain  days. 

b.  Certain  processes  may  best  be  initiated  on  a  recurring 
interval  basis,  where  the  interval  may  not  be  conveniently 
expressed  as  described  in  paragraph  a  above.  In  such 
cases,  an  interval  may  be  set  at  which  a  processor  may  be 
repeatedly  brought  into  execution. 

c.  Non-recurring  specific  times — where  it  is  desirable  to 
execute  a  program  once  at  some  specified  time  in  the  fu¬ 
ture,  the  data/time  may  be  sot  in  the  schedule.  Programs 
may  also  be  initiated  upon  direct  request  of  a  user. 

The  Master  Control  Program  is  initiated  automatically  at  a  fre¬ 
quency  specified  by  the  user  (usually  every  5  minutes).  At 
each  initiation,  it  checks  the  ev'  nt  schedule  file  defining 
processes  to  be  Initiated.  Procerses  to  be  initiated  may  be 
real-time  or  batch  control  point  jobs,  such  as  reports  genera¬ 
tion  or  database  maintenance  processes  or  forecasts.  Entries 
to  the  events  schedule  file  are  made  by  means  of  a  simple  text 
editor.  In  addition  to  scheduling  information,  file  entries 
also  define  initiation  parameters  and  execution  priorities. 

The  Master  Control  Program  also  checks  its  message  queue  upon 
each  initiation.  Messages  are  sent  to  it  by  requests  indicat¬ 
ing  other  programs  to  be  run  and  data  files  to  be  processed. 

The  use  of  messages  allows  many  separate  tasks  to  request  pro¬ 
grams  to  be  run  without  incurring  inter-task  communication  con¬ 
flicts. 

The  Master  Control  Program  is  also  responsible  for  monitoring 
the  status  of  events  taking  place  on  external  communications 
lines.  If  data  flow  from  an  external  source,  such  as  a  front 
end  data  acquisition  machine,  is  disrupted  the  Master  Control 
Program  issues  an  emergency  alert  and  switches  to  alternate 
sources,  or  may  itself  assume  some  responsibilities  of  the 
front  end  data  acquisition  machine,  as  appropriate. 

6. 3. 1.2  Interactive  Input  Control  System  (R2).  The  Interac¬ 
tive  Input  Control  System  provides  the  user  with  convenience 
and  extended  capabilities  in  controlling  and  providing  input  to 
Interactive  and  batch  programs.  The  basic  function  of  the  sys¬ 
tem  is  to  enable  the  user  to  save  and  structure  routine  input 
sequences  for  convenient,  repetitive  use.  This  is  accomplished 
by:  (1)  defining  specific  terminal  keys  as  "functions"  which 
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invoke  a  longer  specific  line  of  input,  (2)  defining  a  sequence 
of  input  lines  as  a  macro  that  can  be  invoked  by  a  single  com¬ 
mand  that  refers  to  the  macro  by  name,  ar.d  (3)  creating  a  menu 
so  that  the  touch  of  a  pen  on  a  graphics  table  responds  with 
one  or  more  characters  of  input.  Macros,  menus,  and  functions 
may  reference  function  keys.  Macros,  menus  and  functions  may 
call  macros.  Also,  functions  and  macros  may  invoke  a  menu  for 
menu  input.  As  indicated,  functions  and  macros  may  be  nested; 
for  example,  a  function  key  may,  in  turn,  be  defined  as  a  com¬ 
bination  of  other  function  keys  as  well  as  ordinary  characters. 
One  macro  may  call  another  macro. 

The  Interactive  Input  Control  System  consists  of  a  library  of 
routines  that  are  linked  with  interactive  programs.  Functions, 
macros  and  menus  are  all  defined  in  files  which  are  specific  to 
the  individual  user.  The  files  can  be  conveniently  edited  with 
a  text  editor,  resulting  in  maximum  flexibility.  In  addition, 
functions  and  macros  may  be  defined  or  redefined  within  an  ac¬ 
tual  interactive  program  execution. 

The  implementation  of  the  Interactive  Input  Control  System  in 
an  interactive  program  is  depicted  in  Figure  6-4. 

A  user's  input  line  from  the  keyboard  (shown  at  left  side  of 
figure)  is  intercepted  by  the  input  interpreter  (at  center)  be¬ 
fore  any  of  the  line  is  passed  to  the  Interactive  program. 

(The  input  interpreter  is  actually  one  or  more  subroutines 
linked  with  the  basic  interactive  program.)  The  input  inter¬ 
preter  examines  the  Intercepted  line  to  see  if  is  a  directive 
to  the  Interactive  Input  Control  System  or  contains  function 
character  references. 

If  the  line  is  an  Interactive  Input  Control  system  directive, 
then  the  directed  task  is  performed  (by  directive  processer  at 
right)  and  a  prompt  is  issued  at  the  user's  terminal  for  fur¬ 
ther  input.  Examples  of  tasks  include  initiation  of  a  macro  or 
definition  of  a  function  character. 

If  the  user  input  line  is  data  for  the  interactive  program,  the 
line  is  examined  for  references  to  functions,  the  character 
strings  defined  by  the  functions  are  substituted  in  their 
place,  and  the  expanded  line  is  passed  to  the  basic  interactive 
program.  The  function  character  definitions  are  stored  in  the 
function  file  (top  left). 

The  macro  and  menu  file  (top  center)  essentially  store  user  in¬ 
put  for  repetitive  use.  Macros  are  invoked  by  name  with  direc¬ 
tives  to  the  input  interpreter  which  cause  the  lines  of  the 
macro  to  be  read  from  the  macro  file.  Macro  lines  are  treated 
as  if  they  were  lines  from  the  user's  keyboard.  In  the  reverse 
process,  user  input  lines  from  the  keyboard  may  be  selectively 
saved  in  the  macro  file. 


6-24 


The  menu  file  contains  coordinates  of  areas  on  the  graphics 
tablet  and  corresponding  character  strings  to  be  used  as  inter¬ 
active  program  input.  Input  from  the  graphics  tablet  (left 
center)  consists  of  the  .oordinates  of  a  point  on  the  tablet 
touched  by  the  input  pen.  The  input  coordinates  are  matched  to 
the  proper,  pre-defined  area,  and  the  sequence  of  characters  is 
passed  to  the  input  interpreter  where  they  are  treated  as  if 
they  came  from  the  user's  keyboard. 

The  log  file  (top  right)  can  optionally  be  used  to  record  all 
input  to  a  program  for  error  tracking  and  other  purposes. 

The  Interactive  Input  Control  System  provides  other  useful  ca¬ 
pabilities  in  addition  to  the  basic  interactive  functions.  The 
system  allows  the  interactive  user  to  interrupt  the  current 
program  he  is  in,  initiate  other  programs,  or  issue  JCL  com¬ 
mands  or  edit  files  and  then  resume  execution  at  any  [joint  in 
the  Interactive  program. 

A  log  of  all  lines  input  to  the  program  may  be  written  to  the 
session  log.  In  this  way  a  session  log  can  become  a  valuable 
history  of  all  input  required  to  perform  a  given  analysis.  It 
may  aid  in  reconstructing  forgotten  steps,  or  in  tracking  er¬ 
rors. 


6 . 3 . 1 . 3  Interactive  Executive  Control  Program  (R3).  The  In¬ 
teractive  Executive  Control  Program  provides  control  of  all  in¬ 
teractive  programs  from  a  single  processor.  Just  as  the  Master 
Control  Program  provides  control  over  all  automatic  processes, 
so  the  Interactive  Executive  Control  Program  provides  control 
over  all  interactive  processes.  It  also  contributes  to  a  uni¬ 
form  input  syntax  and  makes  available  the  features  of  the  in¬ 
teractive  input  control  system  by  bypassing  the  host  computers 
JCL. 

This  routine  is  the  normal  means  by  which  the  interactive  user 
gains  access  to  the  programs  he  desires  to  run.  From  the  In¬ 
teractive  Executive  Control  Program  all  other  interactive  pro¬ 
grams  may  be  invoked.  The  use  of  this  approach  allows  one 
entry  point  into  the  system  to  exist. 

The  user  is  identified  when  he  initiates  the  Executive  Control 
Program  and  is  permitted  to  run  only  those  programs  appropriate 
to  his  task.  Furthermore,  the  interactive  user  need  not  know 
any  system  job  control  language  (JCL)  as  the  Executive  Control 
Program  will  call  up  the  desired  routines  for  the  user.  After 
signing  on  to  the  host  computer  system,  the  Interactive  Execu¬ 
tive  Control  Program  is  initiated  by  the  system.  The  program 
checks  the  user  access  code  and,  if  the  check  is  positive,  au¬ 
tomatically  Initiates  any  preliminary  processes  necessary  for 
the  task.  Once  the  preliminary  processes  are  complete,  the 
user  initiates  any  programs  in  the  selection  offered  by  the  Ex¬ 
ecutive  Control  Program.  A  schematic  depicting  the  hierarchy 
of  control  achieved  with  Interactive  Control  Programs  is 
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presented  in  Figure  6-5.  As  shown  in  Figure  6-5,  alternative 
executive  control  programs  are  used  depending  on  the  role  of 
the  user  and  his  tasks  in  water  control  data  management  and 
analysis.  The  appropriate  executive  control  program  is  initi¬ 
ated  from  job  control  language  as  part  of  the  logon  procedure 
based  on  the  user's  logon  identification  (upper  middle  box). 
Once  the  respective  interactive  executive  program  is  Initiated, 
the  user  has  direct  control  over  an  array  of  other  interactive 
programs  routinely  used  in  accomplishing  his  particular  water 
control  tasks  with  all  of  the  features  of  the  Interactive  Input 
Control  System,  such  as  macros  and  functions.  The  water  con¬ 
trol  manager  (upper  left-hand  box)  typically  uses  Analysis 
Group  Programs  such  as  a  streamflow  forecast  model.  The  system 
manager  (upper  right  hand  box)  is  normally  concerned  with  Data¬ 
base  Utility  Programs  in  maintaining  and  achieving  the  data 
base  and  generating  routine  reports. 

Although  the  functional  needs  of  the  project  and  system  mana¬ 
gers  in  many  cases  involve  distinctly  different  programs,  they 
also  share  needs  for  certain  functions.  These  overlapping  re¬ 
quirements  are  met  by  providing  direct  access  to  commonly  used 
programs,  such  as  the  Display  and  Graphical  Edit  Mathpack  pro¬ 
grams  (at  the  center  of  the  figure).  In  addition,  other  inter¬ 
active  programs  which  are  only  occasionally  used  can  be 
indirectly  initiated  from  the  respective  executive  control  com¬ 
mands  by  means  of  special  chaining  features. 

When  a  user  running  in  executive  control  program  initiates 
another  interactive  program,  control  is  passed  to  the  new  pro¬ 
gram  until  the  user  terminates  the  new  one,  at  which  control  is 
returned  to  the  executive  control  program.  For  example,  if  a 
project  manager  has  logged  on  desiring  to  perform  a  streamflow 
forecast,  he  initiates  the  interactive  streamflow  forecast  mod¬ 
el  pre-processor  by  a  command  to  the  executive  control  program. 
The  executive  control  program  then  initiates  and  passes  control 
to  the  streamflow  forecast  pre-processor  (lower  left  on  the 
figure).  By  issuing  commands  to  the  pre-processor,  the  project 
manager  prepares  and  initiates  a  batch  job  for  the  streamflow 
forecast  model  (lower  left).  The  project  manager  then  termi¬ 
nates  the  pre-processor  and  is  returned  to  the  executive  con¬ 
trol  program  from  where  he  can  initiate  other  functions. 

6. 3. 1.4  Inter-Computer  Job  Control  (R4).  The  purpose  of 
Inter-Computer  Job  Control  is  to  enable  the  implementation  of 
water  control  system  software  on  multiple  host  computers,  with 
part  of  the  system,  field  data  entry,  for  example,  on  one  com¬ 
puter  and  the  analysis  routines  on  another. 

Inter-computer  Job  Control  consists  of  macros  and  procedures 
that  utilize  the  initiating  computer's  resident  remote  job  en¬ 
try  (RJE)  capabilities  to  run  a  job  on  its  alternate  system 
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which  acts  as  a  host.  Although  control  over  the  process  lies 
with  the  computer  which  initiates  the  job  via  RJE,  control  may 
alternate  between  computers  during  the  individual  steps  of  any 
given  process  since  the  host  may  be  directed  to  initiate  an  RJE 
in  turn  back  to  the  original  RJE  site  who  would  then  act  as  a 
host. 

6.3.2  Database  Routines.  The  Database  Routines  consists  of  a  gen¬ 
eralized  set  of  library  routines  for  performing  basic  database  op¬ 
erations  together  with  specialized  database  interface  programs:  the 
Database  Entry  Program  (D3)  and  the  Internal  Database  Transfer. 
These  specialized  programs  are  key  links  in  the  structure  of  the 
Water  Control  System. 

6. 3.2. 1  Database  Library  Routines  (D5).  The  Database  Library 
Routines  contain  a  generalized  set  of  subroutines  which  perform 
basic  database  operations  on  either  the  master  or  time  series 
data  bases,  including  access  control,  data  record  storage,  re¬ 
trieval,  deletion  and  inventories,  and  database  compression. 
These  subroutines  are  linked  with  individual  applications  and 
support  programs  to  affect  integration  of  the  basic  Water  Con¬ 
trol  System  by  providing  communications  between  the  data  base 
and  individual  application  programs. 

The  subroutines  in  the  library  are  modular  in  structure:  each 
performs  a  distinct,  elemental  operation.  Complex  operations 
are  accomplished  using  combinations  of  the  elemental  routines. 
Together,  the  subroutines  comprise  a  coherent  system  for  data¬ 
base  access  and  management. 

6. 3. 2. 2  Database  Entry  Program  (D3).  The  purpose  of  the  Data¬ 
base  Entry  Program  is  to  enter  observed  and  converted  data  into 
the  master  data  base.  The  program  reads  data  from  a  file  of 
valid  data  created  by  the  Data  Conversion  and  Screening  Program 
(A8),  retrieves  the  corresponding  record  block  from  the  data 
base,  enters  the  new  data  into  the  data  block,  and  writes  the 
updated  block  back  into  the  data  base.  If  the  record  block 
does  not  already  exist  in  the  data  base,  it  is  created. 

The  Database  Entry  Program  is  initiated  by  periodic  calls  from 
the  Data  Conversion  and  Screening  Program  based  on  the  number 
of  entries  that  the  conversion  program  has  made  into  the  file. 
When  initiated,  the  Database  Entry  Program  checks  for  the  exis¬ 
tence  of  the  earliest  written  valid  data  file  and  enters  that 
data  into  the  data  base.  If  the  program  is  already  busy  when 
called,  the  request  is  Ignored.  When  the  file  length  limit  is 
reached,  it  ends  the  current  file,  checks  for  the  presence  of 
another  file  to  be  entered  and  begins  the  new  one  if  present. 

The  Database  Entry  Program  executes  as  a  batch  control  point 
job  at  priority  level  6.  Only  one  program  execution  is  permit¬ 
ted  at  a  time  to  reduce  multiple  database  access  activity. 
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6. 3. 2. 3  Internal  Database  Transfer  (D6).  The  Internal  Data¬ 
base  Transfer  program  moves  related  data  between  the  Master  Da¬ 
tabase,  Time  Series  Database,  and  the  Reports  Database  for 
subsequent  references  by  the  analysis  program  group  and  the  Re¬ 
port  Generator  Program.  The  selection  of  data  Is  based  on  in¬ 
formation  contained  In  a  sequential  file  read  by  the  Internal 
Database  Transfer  program  during  its  execution.  Data  values 
from  the  Master  Database  are  converted  in  alphanumeric  forms 
and  missing  values  are  annotated.  Occurrences  of  missing 
blocks  of  data,  which  would  indicate,  for  example,  that  dally 
averaging  had  not  been  performed,  are  written  to  an  error  file 
and  a  message  is  sent  to  alert  the  database  manager  and  refer 
him  to  the  error  file.  Finally,  the  data  are  stored  in  the  re¬ 
ports  data  base  or  time  series  (analysis  program  group)  data 
base.  The  Internal  Database  Transfer  program  is  normally  ini¬ 
tiated  on  a  schedule  by  the  Master  Control  Program:  it  usually 
executes  during  offpeak  hours  as  a  batch  job. 

6.3.3  Records  Routines.  The  Records  Routines  consists  of  subrou¬ 
tine  libraries  and  programs  which  are  involved  in  recording  and  an¬ 
alyzing  records  of  several  water  control  management  processes. 
Records  routines  provide  important  information  on  program  perfor¬ 
mance,  resource  utilization,  tasks  accomplished,  data  entry  and 
other  information  needed  for  system  management. 

6. 3. 3.1  Program  Execution  Log  Entry  (LI).  The  Program  Execu¬ 
tion  Log  is  a  file  that  contains  a  record  of  all  executions  of 
programs  in  the  system.  Entries  are  made  at  the  initiation  and 
termination  of  program  execution  and  show  the  program  identifi¬ 
cation,  the  date  and  time,  the  user  identification,  the  termin¬ 
ator  control  point  identification,  the  resources  used  during 
execution,  and  abnormal  termination  conditions.  This  log  is 
analyzed  by  the  Program  Execution  Analysis  for  basic  usage  and 
performance  statistics  such  as  frequency  of  use,  time  of  use, 
failure  rates  and  average  resources  used. 

Since  simultaneous  log  entries  are  possible,  access  to  the  log 
file  must  be  controlled.  This  is  accomplished  by  the  use  of 
the  system  message  capability.  Log  entries  are  actually  en¬ 
tered  into  a  message  instead  of  directly  into  the  file.  Then, 
a  real-time  program  accepts  the  messages  and  writes  them  to  the 
log  file.  This  program  is  initiated  automatically  by  the  Mas¬ 
ter  Control  Program. 

6. 3. 3. 2  Program  Execution  Analysis  (L2).  Reports  on  program 
execution  are  produced  from  the  Program  Execution  Log  file  by 
the  Program  Execution  Analysis  routine.  This  program  computes 
simple  statistics  on  usage  and  performance  such  as  frequency  of 
Initiation,  the  time  distribution  of  initiations,  the  durations 
of  executions,  number  of  initiations  by  user,  and  failure 
rates.  These  statistics  are  printed  in  a  standard  format  and 
reviewed  and  saved  by  the  system  manager  for  the  purpose  of 
identifying  and  solving  problems  involving  the  dynamics  of  sys¬ 
tem  operation. 
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6.3. 3. 3  Operations  Log  (L3).  The  purpose  of  the  Operations 
Log  is  to  record  key  communications  between  the  District  Water 
Control  center  and  project  offices,  such  as  gate  setting  in¬ 
structions  and  verifications. 

Entries  of  this  log  are  made  in  one  of  two  ways.  When  communi¬ 
cations  between  the  water  control  center  and  project  office  are 
accomplished  by  means  of  a  Water  Control  System  communications 
program,  a  verbatim  copy  of  all  transmissions  may  be  entered 
into  the  log  by  selecting  an  option  in  the  communication  pro¬ 
gram.  When  other  communication  paths  are  used,  such  as  radio 
or  telephone,  independent  entries  are  made  by  both  parties  from 
their  respective  sites  by  means  of  the  Operations  Log  Entry 
Program.  Regardless  of  which  path  is  used  to  record  operations 
communications,  all  entries  are  annotated  by  date,  time,  and 
user  and  terminal  identification. 

The  Operations  Log  is  a  normal  sequential  file.  A  separate  Op¬ 
erations  Log  is  kept  for  each  project,  and  project  managers  are 
responsible  for  managing  their  respective  logs. 

6. 3. 3. 4  Interactive  Session  Log  (L4).  The  Interactive  Session 
Log  is  written  by  the  Interactive  Input  Control  System.  It  is 
simply  a  sequential  file  containing  a  record  of  all  user  input 
lines  to  Interactive  programs  and  its  corresponding  interpreta¬ 
tion  by  the  Interactive  Input  processor  as  seen  by  the  interac¬ 
tive  program.  Its  purpose  is  to  provide  the  user  with  an 
immediate  recall  of  input  during  an  interactive  session.  The 
log  can  be  displayed  at  any  time  at  the  user's  terminal  by 
listing  the  file.  An  Interactive  Session  Log  is  kept  for  each 
user. 

6.3.4  Communications  Routines  (S).  The  Communications  Routines 
consists  of  specialized  programs,  shared  library  routines,  JCL 
macros,  and  resident  host  computer  routines  with  the  specific  pur¬ 
pose  of  enabling  various  modes  of  computer-based  communications, 
mainly  text  and  plot  files,  among  users  on  the  same  host  computer 
and  between  two  or  more  discrete  host  computers,  each  with  multiple 
users.  The  specific  communications  paths  important  in  the  water 
control  environment  include:  (1)  messages;  (2)  bulletin  boards; 

(3)  program  documentation;  (4)  multiple-user,  remote  conferencing; 
(5)  inter-computer  transmission  of  data,  documents,  reports,  and 
plots.  These  paths  are  described  below  as  if  they  were  independent 
and  discrete.  In  reality,  host  computer  routines  typically  support 
a  wide  variety  of  paths,  since  communications  are  important  in 
nearly  all  applications,  the  paths  described  can  be  modified  and 
linked  in  many  combinations. 

6.3.4. 1  Messages  (SI).  Messages,  in  the  communications  con¬ 
text,  are  relatively  short  blocks  of  text  that  can  be  addressed 
from  one  user,  or  program  to  another  user  program  or  terminal. 

A  message  Is  analogous  to  a  postcard.  It  is  short,  and  must  be 
addressed  to  its  destination.  The  destination  is  actually  not 
the  user,  but  a  location  where  the  addressee  must  look  to  dis¬ 
cover  the  message,  just  as  someone  looks  in  a  mailbox. 
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The  message  function  is  resident  on  many  host  computer  systems. 
In  some  systems,  the  message  may  originate  from  a  user's  JCL 
call  and  from  programs.  Messages  may  be  addressed  to  a  partic¬ 
ular  user,  terminal,  or  program,  or  all  of  these.  The  message 
may  persist  over  a  specified  length  of  time,  or  may  be  elimi¬ 
nated  after  initial  reception. 

In  the  Water  Control  System,  messages  are  sent  by  means  of  JCL 
macros  and  by  calls  to  the  resident  routines  from  executive- 
level  control  programs  or  the  user's  command.  Messages  are  re¬ 
ceived  by  similar  paths.  In  addition,  messages  may  be  set  to 
appear  on  user  terminals  as  part  of  the  sign-on  or  sign-off 
macros  so  that  they  are  not  missed  by  the  addressee. 

Text  files  may  be  used  in  conjunction  with  messages  to  relay 
longer  pieces  of  information.  The  addressee  is  simply  told  by 
the  message  to  look  at  the  file  where  the  information  is  con¬ 
tained  . 


6. 3. A. 2  Bulletin  Boards  (S2).  The  bulletin  board  is  used  to 
display  information  to  users  in  general  for  various  purposes, 
including:  (1)  news  of  Water  Control  System  events,  changes, 

problems  and  policies;  (2)  news  of  important  hydrologic  events, 
including  NWS  forecasts;  (3)  any  reports  for  individual  proj¬ 
ects  or  basins;  (4)  organization-related  matters  such  as  per¬ 
sonnel  announcements,  work  schedules,  and  assignments. 

Implementation  of  the  bulletin  board  function  is  accomplished 
by  simpLy  creating  text  files  and  allowing  general  access  to 
those  files.  Certain  bulletin  board  files  can  be  printed  auto¬ 
matically  within  user  sign-on  procedures.  This  implementation 
provides  virtually  complete  flexibility  to  suit  particular  wa¬ 
ter  control  organizations:  the  names  and  contents  of  bulletin 
board  files  are  left  completely  to  the  discretion  of  users  man¬ 
agement  . 


6. 3.4. 3  Documentation  (S3).  A  set  of  documents  providing  In¬ 
formation  on  Water  Control  System  software  Is  stored  in  files 
and  available  to  users  for  listing  at  Interactive  terminals  or 
on  a  line  printer.  This  material,  available  from  the  computer 
system.  Is  referred  to  as  "on-line"  documentation.  In  addi¬ 
tion,  interactive  programs  provide  explanations  of  their  use 
during  interactive  sessions.  This  documentation,  available 
with  the  program.  Is  referred  to  as  "in-line"  documentation. 

Software  documentation  generally  contains  information  regarding 
program  capabilities,  relationship  to  other  software  compo¬ 
nents,  and  explanations  and  Instructions  for  using  the  particu¬ 
lar  component.  Documentation  would  be  provided  for  both 
Individual  programs,  shared  routine  libraries,  and  JCL  macros. 
Other  documentation  would  describe  and  explain  file  organiza¬ 
tion,  file  naming  conventions,  overall  system  structure  and 
functioning,  and  training  guides. 
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The  documentat Ion  would  be  contained  in  a  set  of  flies,  each 
file  containing  documentation  on  one  or  a  series  of  related 
components  or  topics.  In  addition,  an  index  file  would  list 
all  documentat ion  topics  and  corresponding  file  names  and  pro¬ 
vide  brief  descriptions  of  components. 

In-line  documentation  consists  of  explanations  of  command  op¬ 
tions.  Explanation  of  specific  options  may  be  displayed  at  the 
user's  terralnaL  during  an  interactive  session  by  a  user  request 
naming  the  option.  The  in-line  documentation  is  read  by  the 
Interactive  program  from  an  attached  text  file.  These  files 
may  be  edited  by  the  program  or  system  manager  using  a  standard 
text  editor. 

6. 3.4.4  Remote  Conferencing  System  (S4).  The  Remote  Confer¬ 
encing  Program  enables  concurrent  display  of  text  files, 
including  reports  and  bulletins,  to  multiple  users  for  confer¬ 
encing  purposes.  In  addition,  interactive  programs  are  capable 
of  displaying  results  to  multiple  users,  including  plots. 

The  Remote  Conferencing  Program  is  an  interactive  program  which 
simply  reads  text  files,  such  as  reports,  bulletins,  or  docu¬ 
mentation,  and  simultaneously  lists  the  file  at  several  user 
terminals.  The  program  provides  user  control  over  listing  by 
accepting  line  number  range  specifications. 

Both  the  Remote  Conferencing  Program  and  other  Interactive  pro¬ 
grams  with  remote  display  capabilities  rely  on  the  availability 
of  the  receiving  terminal:  It  must  be  on,  but  not  logged  on  to 
the  host  computer's  executive  program.  The  receiving  terminal 
is  then  treated  as  any  other  physical  output  device,  and  as  a 
line  printer,  and  output  is  sent  to  all  connected  terminals. 
Control  of  the  process  resides  with  the  user  who  initiates  the 
Interactive  program. 

11.3.4.5  Inter-Computer  Communications  (S5).  Inter-Computer 
Communications  depend  upon  the  RJE  capabilities  of  the  local 
host  computer,  as  described  in  paragraph  6. 2. 2. 5,  and  special 
encoding  and  decoding  programs  on  the  Local  and  remote  compu¬ 
ters,  respectively. 

Coded  files  may  be  transmitted  to  remote  sites  by  means  of  lo¬ 
cal  host  resident  routines.  Data  values,  documents,  and  re¬ 
ports  alL  may  be  transmitted  this  way.  Database  files  are  not 
coded,  and  would  require  encoding  and  decoding  for  Inter¬ 
computer  transmission.  Database  utilities  perform  these  func¬ 
tions. 
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Likewise,  plot  files  which  drive  off-line  plotting  devices, 
such  as  Calcorap,  are  not  necessarily  coded  and  also  need  spe¬ 
cial  encoding  and  decoding  programs.  However,  it  is  easier  and 
more  flexible  to  transmit  the  data  to  be  plotted  and  rely  on 
general  plotting  programs  at  the  remote  site  just  as  they  would 
plot  local  data.  By  including  the  data  within  a  JCL  and  plot¬ 
ting  macro  file,  plotting  at  the  remote  site  can  be  controlled 
by  the  local  user  if  off-line  devices  are  used. 

The  transmission  process  obviously  involves  a  control  sequence 
using  several  programs.  Simplification  of  the  control  of  rou¬ 
tine  transmissions  is  accomplished  through  the  use  of  JCL  macro 
files,  and  the  entire  procedure  may  be  run  as  a  batch  control 
point  job. 

To  further  simplify  transmissions  procedures,  any  decoding  at 
remote  sites  is  controlled  by  means  of  JCL  contained  in  RJE 
transmissions.  Under  this  convention,  the  user  at  the  receiv¬ 
ing  end  need  take  only  a  passive  part  in  the  transmission  pro¬ 
cess,  and  only  view  the  results. 

6.3.5  Training  Aids.  Certain  components  of  the  Water  Control  Sys¬ 
tem  have  features  and  intrinsic  characteristics  that  facilitate 
training  of  personnel  in  water  control  operations.  Of  particular 
interest  is  the  use  of  the  Analysis  Group  to  train  individuals. 

This  group  allows  the  analysis  of  both  realtime  events  as  well  as 
historical  events. 

6. 3. 5. I  Documentation.  Documentation  contained  in  files  ac¬ 
cessible  to  all  users  provides  essential  information  on  what 
system  components  do,  how  they  work,  and  how  they  are  used. 
These  are  more  fully  described  in  paragraph  6. 3. 4. 3. 

b.3.5.2  Interactive  Features.  The  self-document ing ,  self- 
guiding  nature  of  all  interactive  programs  make  them  useful  in 
training.  All  interactive  programs  provide  on-line  display  of 
available  command  options  and  explanations  of  individual  com¬ 
mands  selectable  at  user  request  at  virtually  any  time  during 
an  interactive  session.  With  the  information  provided,  the 
user  not  only  learns  about  command  options  and  their  input  re¬ 
quirements  and  consequences,  he  also  may  infer  the  logical 
structure  underlying  the  particular  programs  operation. 

Another  feature  of  interactive  programs  useful  in  training  is 
error  handling  when  the  logical  sequences  of  program  use  is 
violated  or  when  typing  errors  are  made  on  input. 
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6. 3. 5. 3  Simulation.  Many  of  the  operations  performed  in  the 
Water  Control  System  may  be  readily  simulated  with  actual  pro¬ 
grams  and  data  without  affecting  the  normal  stream  of  opera¬ 
tions  and  without  special  additional  programs.  This  is 
accomplished  by  the  use  of  special  data  files  created  and  main¬ 
tained  separate  from  their  normal  system  counterparts,  and  is 
made  possible  by  the  systematic  reliance  on  information  con¬ 
tained  in  files  rather  than  embedded  in  software  to  describe 
key  system  characteristics. 

Simulations  of  hypothetical  or  major  historic  flood  events  are 
an  important  example  of  Water  Control  System  capabilities.  The 
use  of  a  specially  created  data  set  with  a  basic  hydrologic  de¬ 
scription  of  the  event  is  the  basis  for  these  kind  of  simula¬ 
tions.  Special  extractions  of  the  data  base  are  made  for 
specific  forecast  times  which  only  include  data  up  to  the  fore¬ 
cast  time.  Users  then  interactively  screen,  display  and  change 
data,  and  perform  forecasts  and  operations  simulations  as  bases 
for  operational  decisions. 

Although  the  simulations  data  base  is  separate  from  the  normal 
one,  copies  of  other  user  files  may  be  identical  with  the  nor¬ 
mally  used  ones.  For  example,  model  files,  JCL  macros,  and 
user  defined  input  functions,  macros  and  menus  could  all  be  the 
same  as  used  in  actual  operations. 

6.4  Interactions  Between  Individual  Programs.  The  thoughtful  design 
of  program  interaction  is  essential  to  achieving  a  water  control  soft¬ 
ware  system  that  is  coherent  and  comprehensive,  yet  is  highly  flexible, 
reliable,  sinple  and  straightforward.  The  desires  for  an  understanda¬ 
ble  underlying  logic,  simplicity,  and  flexibility  together  with  con¬ 
straints  on  core  memory  and  disk  storage  require  that  the  overall 
system  be  an  ensemble  of  individual  programs  functioning  virtually  as  a 
single  program.  The  programs  are  Integrated  as  system  modules  In  terms 
of  both  communications  and  control. 

6.4.1  Communications .  Communications  among  water  control  software 
components  affect  structural  Interaction  of  the  system.  Structural 
integration  of  water  control  programs  consists  of  facilitating  the 
systematic  flow  of  information  among  the  program  modules.  Each 
module  has  a  unique,  specific,  and  essential  role  in  the  processing 
of  Information,  and  the  connections  between  modules  utilize  a  com¬ 
mon  format  and  exchange  protocol. 

For  the  water  control  system,  the  basic  Information  flow  consists 
mainly  of  hydrometeorological  time-series  data  together  with  two- 
and  three  dimensional  spatial  data  and  site  data  describing  the 
physical  characteristics  of  the  prototype  hydrologic  system.  The 
structural  relationships  among  water  control  applications  software 
is  depicted  in  Figure  6-1. 


The  specific,  local  communications  schemes  rely  on  a  full  array  of 
standard  computer  features  as  well  as  host-specific  applications  of 
standard  features.  The  standard  features  include  files,  CPU  regis¬ 
ters,  and  memory  areas.  Host-specific  services  which  are  based  on 
these  standard  features  include  indexed  files,  addressable  mes¬ 
sages,  and  shared  common  areas . 

Messages  are  common,  host-specific  services.  Messages  can  be  sent 
by  programs,  job  control  language,  and  interactive  users.  They  can 
be  addressed  to  particular  users,  programs  or  physical  devices. 
Messages  are  stored  on  disk  areas  and  managed  by  host  software. 

Messages  are  important  to  the  integrated  functioning  of  the  water 
control  system.  They  allow  straightforward  and  simple  exchange  of 
short  pieces  of  information  among  users  and  program.  The  exchange 
requires  no  direct  coupling  between  programs,  addresses  are  logic¬ 
ally  based  on  program  and  user  names,  and  accounting  is  transparent 
to  user  programs.  Both  control  parameters  and  data  are  passed  with 
messages . 

Entries  to  the  Program  Execution  Log  are  made  using  messages  to  a 
log  entry  program.  This  scheme  decouples  message  writing  and  file 
availability  avoiding  the  problem  of  a  simultaneous  write  attempt 
by  two  or  more  programs.  Emergency  alert  messages,  to  the  Emergen¬ 
cy  Alert  Program  (paragraph  6.2.1.10)  and  the  Master  Control  Queue 
(paragraph  6. 3.1.1)  are  accomplished  with  a  similar  scheme. 

Botli  shared  memory  areas  and  files  are  used  to  buffer  the  transfer 
of  large  volumes  of  data  from  communications  programs  to  the  Data 
Conversion  and  Screening  Program  (paragraph  6. 2. 1.8).  Data  are  re¬ 
ceived  and  processed  by  the  communications  programs  at  rapid  rate. 
The  Data  Conversion  and  Screening  Program  however,  processes  data 
more  slowly,  requiring  a  longer  period  of  time  for  the  same  volume 
processed  by  a  communications  program.  Consequently,  the  data 
transferred  between  them  require  temporary  storage,  or  buffers.  A 
shared  memory  area  is  used  primarily  since  its  use  is  more  direct 
and  involves  fewer  physical  steps.  However,  files  have  the  virtue 
of  being  safe  against  system  failure  since  they  are  saved  on  disk, 
if  memory  buffers  are  primarily  used,  files  must  be  used  to  store 
overflow  from  the  buffers. 

h.4.2  Control.  The  water  control  system  utilizes  inter-program 
control  to  achieve  coherent  operation.  "Inter-program  control" 
means  a  given  program  has  the  ability  to  initiate,  hold,  suspend  or 
terminate  the  execution  of  other  programs. 
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6.4.2. 1  Initiation  and  Sequencing.  Certain  programs  must  run 
at  regular,  specific,  pre-determined  times.  These  include  some 
of  the  data  communications  programs  and  the  Report  Generator. 
For  convenience  and  reliability,  these  programs  are  scheduled 
in  advance  to  be  initiated  by  the  Master  Control  Program 
(paragraph  6. 3.1.1). 

Other  programs  perform  parts  of  a  larger,  sequential  task,  such 
as  the  overall  data  acquisition  process,  and  their  initiation 
depends  on  the  completion  of  the  preceding  steps. 

The  successive  initiations  of  programs  involved  at  the  various 
steps  are  accomplished  in  two  different  ways.  One  is  use  of  a 
JCL  procedure  file.  This  alternative  is  appropriate  when  the 
sequence  is  relatively  fixed.  The  other  alternative  is  a  re¬ 
quest  to  the  Master  Control  Program  via  a  message  entry  into 
its  queue.  This  is  appropriate  for  sequences  which  may  be  al¬ 
lowed  delays  between  steps.  The  internal  logic  and  related 
schedule  files  of  the  Master  Control  Program  provide  a  capabil¬ 
ity  of  arbitrating  the  future  scheduling  of  the  initiations  of 
programs  in  its  queue  and  on  its  schedule  as  required  to 
achieve  an  orderly  and  timely  completion  of  all  tasks  within  a 
desired  level  of  loading  on  the  host's  CPU  resources. 

Interactive  programs  typically  are  used  in  a  variety  of  se¬ 
quences  which  cannot  be  scheduled  beforehand.  Logical  groups 
of  interactive  programs  are  controlled  with  respective  Interac¬ 
tive  Executive  Control  programs  (paragraph  6. 3. 1.3).  For  exam¬ 
ple,  the  water  control  project  manager  will  use  Analysis  Group 
programs,  the  Graphical  Display  and  Edit  programs,  and  the 
Database  Utility  Program  in  ordinary  interactive  sessions. 

The  Interactive  Control  Programs  for  this  group  clears  users' 
access  codes,  defines  global  parameters  for  the  session,  such 
as  basin  name,  automatical ly  initiates  housekeeping  processes, 
and  controls  the  sequence  of  interactive  program  executions  ac¬ 
cording  to  the  user's  directives. 

Support  programs  which  perform  continuous  control,  logging,  or 
monitoring  tasks  are  real-time  programs  which  are  initiated  at 
specific  frequencies  by  the  host  system.  Initiation  frequen¬ 
cies  are  variable  and  are  specified  by  the  system  manager. 

These  programs  include  the  Master  Control  Program  (paragraph 
n.3. 1.1)  and  the  Program  Execution  Log  Entry  Program  (paragraph 
6.3.3. 1). 

6.4. 2. 2  Processing  Priorities.  A  hierarchy  of  priorities  is 
assigned  to  individual  programs  in  the  water  control  system. 
This  hierarchy  provides  systematic  arbitration  of  the  sequence 
in  which  contending  tasks  are  to  be  performed  in  order  to  as¬ 
sure  the  timely  completion  of  the  most  important  tasks. 
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The  hierarchy  of  priorities  is  specified  in  two  ways.  First, 
the  host  system  provides  a  means  of  assigning  processing  prior¬ 
ities  to  program  executions  on  an  absolute  scale.  Real-time 
and  batch  jobs  are  explicitly  assigned  priorities  through  JCL 
at  the  time  of  initiation.  Priorities  for  interactive  programs 
are  assigned  according  to  the  priority  of  the  terminal  from 
which  the  job  is  initiated.  The  terminal,  in  turn,  is  assigned 
a  priority  by  the  system  manager  within  overall  system  defini¬ 
tions.  \  chart  of  normal  system  priorities  is  presented  in 
Figure  6-6. 

The  Master  Control  Program  (MCP)  provides  an  alternative  means 
of  assigning  priorities  which  differs  from  system  priorities. 
The  MCP  enables  different  programs  within  a  job  sequence  to  run 
at  different  host  system  priorities.  For  example,  the  Data 
Conversion  and  Screening  Program  is  run  at  a  higher  priority 
than  the  Database  Entry  Program  even  though  the  two  process 
data  sequentially  on  a  routine  basis:  the  screening  of  data  for 
alarms  has  greater  priority  than  database  entry.  Priorities 
within  the  MCP  are  defined  in  a  sequential  fiLe  of  program 
identifiers  and  associated  system  priority  codes. 

6.6  Relationships  Among  Software  Components  and  Requirements.  Inter¬ 
actions  among  individual  software  components  are  potentially  complex: 
components  can  he  linked  in  a  variety  of  sequences  in  order  to  meet  a 
wide  range  of  needs.  Figure  6-6,  however,  presents  a  simplified  view 
of  the  interactions  between  programs  and  the  inter-relat lonships  be¬ 
tween  components  and  common  requirements  in  order  to  facilitate  a  bet¬ 
ter  understanding. 

in  general,  the  matrix  presented  in  Figure  6-7  indicates  specific  soft¬ 
ware  components  Involved  in  meeting  specific  requirements.  Common  re¬ 
quirements  shown  as  labels  to  rows  are  products  and  capabilities 
described  in  Chapter  6.  The  column  labels  are  software  components  and 
groups  of  components  identified  in  this  chapter. 

in  addition  to  indicating  inter-relationships  between  components  and 
requirements,  the  matrix  also  suggests  interactions  between  components 
in  the  processes  involved  in  fulfilling  the  requirements. 

For  applications  components,  numerals  appearing  in  the  row  of  a  specif¬ 
ic  requirement  indicate  that  the  component  is  ordinarily  involved  in 
meeting  the  requirement  in  a  sequence  shown  by  the  numerical  order 
where  several  alternative  components  are  appropriate  at  a  particular 
step  in  sequence,  all  are  given  the  same  step  number.  Where  the  con¬ 
cept  of  a  sequential  order  is  inappropriate,  the  numeral  1  is  used  ex- 
c  lus i vely . 

Support  software,  in  contrast  to  applications  software,  is  typically 
Involved  In  several  steps  of  the  sequential  process  used  in  meeting  re¬ 
quirements;  therefore,  it  is  inappropriate  to  indicate  an  order.  In¬ 
stead,  Letters  are  used  to  show  the  degree  of  importance  In  meeting 
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user  requirements  since  certain  support  components  are  intended  to 
enhance  the  basic  capabilities  to  which  other  support  software  is  es¬ 
sential.  The  degrees  of  importance  are  shown  in  three  levels  corre¬ 
sponding  to  whether  the  component  is  necessary,  preferred,  or  desired 
for  convenience  or  extra  utility. 

The  relationships  among  major  software  groups,  user  actions,  and  user 
requirements  are  also  presented  in  Figure  6-8  which  depicts  the  gener¬ 
alized  fLows  of  data  within  the  Water  Control  Data  System.  Data  values 
for  observations  of  time-variant  hydrologic  variables  comprise  80-90 
percent  of  the  total  flow  and  storage  of  Information  in  the  system: 
Figure  6-8  mainly  depicts  the  flow  of  that  data  through  the  water  con¬ 
trol  data  system's  major  processing  operations.  Some  of  the  principal 
flows  of  user  directives  and  user  products  are  also  indicated. 

8.6  Known  Availability  of  Software  Components.  The  known  availability 
of  software  components  is  presented  in  Figure  6-9.  Individual  compo¬ 
nents  and  systems  are  tabulated  in  the  order  addressed  in  this  chapter. 
Opposite  each  component  are  tabulated  its  principal  functional  require¬ 
ments,  potential  source,  estimated  costs,  and  remarks  pertinent  to  its 
avail abi l ity.  Principally  needed  capabilities  were  compiled  from  de¬ 
scriptions  in  this  chapter.  Costs  of  components  are  judgments  based  on 
expected  relative  length  and  complexity  compared  with  existing  software 
ini  its  related  costs.  The  costs  include  modification  of  reasonably 
close  substitutes  and  documentation,  but  do  not  include  maintenance. 
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2.  Interactive  processes  are  assigned  priority  based  on  the  priority  of  the  terminal  from  which 
thev  are  initiated.  The  terminal's  priority,  in  turn,  is  assiqned  by  the  computer  system 
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7.1  General 


7.1.1  Purpose.  The  purpose  of  this  chapter  is  to  present  soft¬ 
ware  engineering  standards  and  conventions  to  be  used  in  the  de¬ 
sign,  coding  and  checkout  of  software  systems  in  support  of  SWD 
WCDS.  The  goal  of  these  standards  is  to  increase  usability,  reli¬ 
ability,  testability  and  maintainabll ity  by  using  advanced  design 
techniques  and  structured  coding,  thereby  developing  software  pro¬ 
ducts  in  compliance  witii  established  program  budgets  and  sched¬ 
ules.  The  applicability  of  this  chapter  to  existing  software 
shalL  he  determined  by  the  SW!)  KCC  on  a  case  by  case  basis. 

7.1.2  Scope.  The  scope  of  this  chapter  includes:  General  Stan¬ 
dards  and  Conventions,  Design  Conventions,  Coding  Standards  and 
Conventions  for  FORTRAN  Review  Procedures. 

in  tills  chapter,  the  words  module,  subroutine,  and  function  are 
synonymous  and  no  distinction  is  in' ended. 

7.2  General  Standards  and  Conventions. 


7.2.1  Need  for  Standards  and  Conventions.  The  use  of  common 
standards  and  conventions  can  significantly  reduce  both  develop¬ 
ment  and  life  cycle  maintenance  costs  and  increase  progr.im  relia¬ 
bility.  Standard  design  and  programing  techniques  will  facilitate 
modifications  that  occur  during  the  development ''maintenance  phase 
of  the  life  cycle. 

As  a  result  of  the  recent  exposition  and  treatment  in  technical 
literature  of  the  concepts  and  techniques  known  as  "Top-Down  De¬ 
sign,"  "Structured  Design,"  and  "Structured  Programing,"  a  great 
deal  of  attention  has  been  focused  on  the  processes  of  designing 
and  coding  computer  programs.  In  the  past,  the  design  of  many 
individual  programs  evolved  as  the  programer  actually  coded  his 
assigned  functions.  The  design  phase  of  program  development  Is 
now  recognized  to  hi'  a  crucial  factor  in  determining  the  reliabil¬ 
ity  and  efficiency  of  the  software  product.  The  manpower  and  time 
required  to  implement  a  given  program,  as  well  as  life  cycle  sup¬ 
port  costs,  will  be  greatly  influenced  by  the  design  approach  and 
the  design  alternatives  selected. 

7.2.2  The  Design  Process.  The  following  general  requirements 
should  apply  to  the  design  process: 

a.  The  program  design  should  be  carried  out  as  a  separate, 
distinct  activity  resulting  In  a  clear  and  comprehensive  de¬ 
sign  spec i f icat i on . 
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b.  The  design  of  each  component  should  be  completed  and  ac¬ 
cepted  via  the  review  process  before  coding  of  that  component 
can  commence.  This  will  greatly  simplify  the  coding,  testing 
and  further  documentat ion  in  later  stages  of  the  life  cycle. 

c.  For  existing  programs  the  designs  may  be  required  by  di¬ 
rection  of  the  RCC.  Beyond  these  general  requirements,  spe¬ 
cific  design  standards  and  conventions  maximize  the  clarity 
of  the  design  and  the  eventual  reliability  and  maintainabil¬ 
ity  of  the  ultimate  system.  To  this  end,  the  software  system 
should  have  a  logical  structure  with  highly  localized  func- 

t  ions . 

7.2.3  hierarchical  Top-Down  Program  Design.  \  hierarchical  de¬ 
sign  is,  quite  simply,  one  which  is  structured  into  levels.  The 
topmost  level  of  the  hierarchical  structure  corresponds  to  the 
highest  level  of  control  of  the  task  to  be  performed  by  the  pro¬ 
gram.  Lower  levels  of  the  hierarchy,  in  turn,  correspond  to  low 
levels  and  will  only  be  invoked  by  components  at  higher  levels. 
Finally,  each  level  of  the  design  must  be  logically  complete  in 
itself  and  must  be  of  size  which  can  be  readily  viewed  and  compre¬ 
hended.  Such  design  is  easier  to  read  and  implement,  and  will 
lead  to  a  more  easily  maintainable  system,  than  one  consisting  of 
a  single  large,  monolithic  program. 

Ttie  method  of  top-down  design  requires  that  the  basic  control 
functions  of  the  system  (i.e.,  the  topmost  level  of  the  hierarch¬ 
ical  structure)  be  designed  first.  The  flow  of  control  among  the 
modular  functions,  will  then  constitute  the  topmost  level  of  the 
system.  All  control  functions  Invoked  by  the  topmost  modules  will 
be  at  the  second  level,  which  should  be  designed  next,  with  the 
identification  of  modules  at  this  level  also.  This  process  con¬ 
tinues  down  to  the  bottom  level  of  the  program  structures. 

The  high  level  control  components  shall  be  coded  first,  using  dum¬ 
my  statements  to  represent  lower  level  components. 

7 . 3  Design  Standards  and  Conventions. 

7.3.1  Purpose.  The  purpose  of  this  paragraph  is  to  set  forth  the 
standards  and  guidelines  to  be  used  by  the  WCDS  personnel  and  con¬ 
tractors  in  design  of  the  WCDS  software. 

7.3.2  Statement  of  Requirements. 

7.3.2.  I  Introduction.  The  statement  of  requirements  is  a 
written  expression  of  all  that  a  program  will  be  expected 
to  do.  It  should  be  as  complete  as  reasonable,  understand¬ 
ing  that  often  an  Iterative  process  governs  the  development 
of  a  program.  The  Initial  concept  of  the  requirement  is 
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expanded  as  development  occurs.  As  much  as  possible  of 
this  iteration  should  take  place  during  the  preparation  of 
the  statement  of  requirements.  If  requirements  are  signif¬ 
icantly  expanded  after  functional  and  detail  design  or  cod¬ 
ing  has  occurred,  much  effort  may  be  wasted  or  else  the 
product  may  be  poorly  adaptable  to  the  changed  require¬ 
ments.  This  may  result  in  a  heavily  patched,  poorly  per¬ 
forming,  difficult  to  maintain  product.  A  well  thought  out 
statement  of  requirements  will  conversely  contribute  to  the 
development  of  a  well  performing,  easy  to  maintain  pro- 
d  uc  t . 

Most  of  the  requirements  document  should  become  part  of 
either  user  or  programer  documentation  later  in  the  devel¬ 
opment  cycle.  If  done  properly  most  sections  will  need 
only  minor  editing  to  he  included  In  other  documentation. 

In  general,  unnecessary  "requirements"  should  not  be 
stated.  This  will  allow  the  designer  greater  freedom  to 
produce  a  well  performing  product.  However,  if  too  few 
requirements  are  stated,  the  designer  may  have  so  much 
freedom  that  the  end  product  will  not  meet  the  need  for 
which  it  has  been  developed. 

The  statement  of  requirements  should  include  these  areas: 

Purpose  of  Program 

Capability  Requirements 

Interface  Requirements 

Programing  Requirements 

A  sample  statement  of  requirements  Is  given  in  Figure  7-1. 

7.  3.2.2  Purpose  of  Program.  The  purpose  of  the  program 
should  be  stated  briefly.  It  should  be  approximately  a 
paragraph  In  length.  It  should  convey  the  general  function 
of  the  program.  Details  should  be  left  to  the  capabilities 
section.  The  purpose  statement  should  be  synonymous  with 
the  text  portion  of  the  program  abstract.  It  should  orient 
a  reader  to  why  the  program  was  written,  who  would  use  it, 
what  it  does,  and  how  it  does  it  in  brief  terms.  Based  on 
the  purpose  statement  an  individual  is  oriented  to  the  ma¬ 
terial  that  will  follow  in  the  capabilities  and  Interface 
section  of  the  requirements  document.  Later  the  purpose 
statement  will  be  incorporated  into  the  user  and  programer 
documentation  and  the  program  ah«'.ract. 

7. 3. 2. 3  Capability  Requirements.  The  capabilities  section 
contains  specific  statements  of  what  the  program  must  do. 
The  capabilities  section  will  be  used  during  development  to 
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guide  the  functional  design  of  the  program.  This  same  sec¬ 
tion  could  be  used  later  as  part  of  the  user  documentation 
to  inform  the  user  what  the  program  can  do  for  him.  Again, 
if  it  is  written  properly,  it  will  serve  both  purposes  with 
little  or  no  rewriting. 

7. 3. 2. 3.1  Methodology .  This  section  states  the  engineer¬ 
ing  methodology  that  should  be  included,  and  the  options 
required.  The  capabilities  statement  may  be  several  para¬ 
graphs  long  for  a  short  program,  or  may  be  50  or  more  pages 
for  a  complex  program.  The  capabilities  statement  may  ref¬ 
erence  commonly  accepted  techniques.  Those  less  commonly 
known  techniques  should  be  spel Led  out  in  detail.  For 
instance,  if  a  ralnf al 1-runof f-routing  program  were  to  be 
developed,  the  capabilities  section  may  reference  that  the 
Clark  and  Snyder  unit  hydrograph  methods  are  to  be  incor¬ 
porated.  Such  methods  need  not  be  spelled  out  in  detail, 
because  they  are  commonly  recognized  within  the  profession 
and  are  defined  in  available  literature. 

On  the  other  hand,  if  a  new  form  of  a  continuous  loss  func¬ 
tion  were  to  be  included,  the  loss  function  will  need  to  be 
def  i tied  in  detail . 

7. 3. 2. 3-2  Assumptions  and  Limitations-  Theoretical  as¬ 
sumptions  that  will  be  allowed  in  the  application  of  a 
methodology  must  be  specified.  Limitations  of  the  methods 
should  be  stated.  Also,  the  actions  the  program  will  take 
on  detecting  unusual  conditions  that  are  detected,  such  as 
encountering  missing  data,  or  failure  to  converge  to  a 
solution  should  be  stated. 

7.3.2. 3.3  Verification.  It  is  good  practice  to  include 
requi rements  for  specific  tests  that  the  software  must  be 
able  to  execute.  The  tests  specified  will  become  criteria 
by  which  performance  of  the  program  may  be  tested  after 
development,  after  modification,  and  after  implementation. 

7. 3.2. 3.4  Interface  Requirements.  The  interface  section 
of  the  requirements  document  must  define  all  necessary  re¬ 
lationships  between  what  goes  on  Inside  the  program  and  the 
outside  world.  It  must  include  interfaces  to  the  user  and 
ills  input  data  and  output  results.  It  must  Include  Inter¬ 
faces  to  the  computer  system,  disk  units,  and  other  de¬ 
vices  . 

7. 3. 2. 3. 5  Input/Output .  in  most  cases  it  is  quite  impor¬ 
tant  to  state  a  requirement  of  how  the  program  should  ac¬ 
cept  input.  Normally  the  specific  input  structure  would  be 
part  of  the  functional  or  detail  design.  Likewise  the  form 
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of  the  output  should  be  specified  in  either  a  general  or 
specific  way.  The  need  for  tabular  and/or  graphic  output, 
devices  to  be  used,  different  levels  of  detail  in  output, 
and  other  output  options  should  all  be  addressed.  The  re¬ 
quirements  for  verification  (debug)  output  during  develop¬ 
ment  as  well  as  during  the  life  of  the  program  should  be 
specified.  Requirements  to  interface  to  data  bases  should 
be  identified. 

7. 3. 2. 3. 6  System  Requirements.  Requirements  that  deal 
with  computer  system  services  should  be  identified,  such  as 
date  and  time  of  day,  error  recovery  capabilities,  program 
interrupt,  control  and  operator  console  communication. 

7. 3. 2. 3. 7  Programing  Requirements.  Programing  require¬ 
ments  must  be  stated  to  define  the  constraints  upon  the 
program  coder.  These  are  largely  covered  by  standards  set 
forth  elsewhere  in  this  document.  Additional  requirements 
on  memory  size,  language  constructs  permitted  or  excluded, 
maximum  number  of  input/output  units  allowed,  etc.,  may  be 
appropriate.  Treatment  of  error  conditions  should  be  spec¬ 
ified. 

7.3.3  Program  Design.  The  program  design  should  be  carried  out 
as  a  separate,  distinct  activity  resulting  in  a  clear  and  compre¬ 
hensive  design  specification.  The  design  should  be  performed  in 
two  phases.  The  first  phase  is  general  or  functional  design:  a 
global  design  of  the  program  components.  This  phase  determines 
how  the  program  is  to  accomplish  its  functional  objectives.  The 
second  phase  is  the  detailed  design  phase.  This  phase  determines 
the  specific  programing  details  of  how  the  program  will  accomplish 
its  work  in  the  programing  language  and  operating  system  environ¬ 
ment  it  will  use.  The  design  of  each  component  must  be  completed 
and  accepted  via  the  review  process  before  coding  of  that  compo¬ 
nent  can  commence. 

7.3.4  General  or  Functional  Design  Phase.  The  functional  design 
describes  the  basic  steps  involved  in  the  solution  procedure  in 
terms  unrelated  to  any  programing  language.  For  example,  the 
functional  design  of  a  rainfall-  runoff  model  would  describe  the 
process  of  computing  runoff  from  rainfall  in  terms  of  the  basic 
mathematical  models  of  the  process. 

The  functional  requirements  are  transformed  into  program  specifi¬ 
cations  in  the  "FUNCTIONAL  DESIGN"  phase,  using  a  structured 
approach.  The  structured  analysis  approach  has  the  following 
characteristics:  (1)  It  yields  a  description  of  the  program-to- 

be,  typically  using  diagrams  to  communicate  ideas;  (2)  it  pro¬ 
gresses  smoothly  in  a  top-down  fashion,  from  a  global,  general 
definition  of  program  components  to  a  detailed,  in-depth 
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description  of  these  components;  and  (3)  it  yields  a  set  of  con¬ 
nected  specifications  of  the  identified  program  components. 


7. 3. 4.1  Description.  A  general  description  of  the  pro¬ 
posed  program  is  developed  prior  to  its  detail  design  and 
coding.  This  defines  conceptually  the  components  of  the 
program,  the  interaction  and  order  of  execution  of  the  com¬ 
ponents,  and  the  required  flow  of  data  between  components. 
Diagrams  are  usually  convenient  for  presenting  this  portion 
of  information.  All  data  manipulation  and  computation 
techniques  are  defined  in  sufficient  detail  to  permit  the 
detail  program  designers,  and  subsequent  program  users  to 
recognize  the  subdivision  of  tasks  accomplished  by  the  pro¬ 
gram,  to  locate  the  components  In  which  the  tasks  are  ac¬ 
complished,  and  to  understand  the  computational  techniques 
and  algorithms  employed.  These  goals  are  best  met  using 
the  top-down  design  technique  described  herein.  The  gener¬ 
al  format  of  input  and  output  is  especially  critical,  and 
its  design  should  be  included  at  this  stage  of  program  de¬ 
velopment.  A  preliminary  input  guide  should  be  de'eloped, 
and  output  report  forms  should  be  defined.  Potential  pro¬ 
gram  users  should  be  consulted  to  verify  the  practicality 
and  availability  of  the  input  and  the  utility  of  the  out¬ 
put  . 


7. 3.4.2  Top-Down  Design.  Top-down  program  design  begins 
with  firmly  established  program  requirements  for  tasks  to 
be  accomplished  by  the  program  and  with  definition  of  the 
data  required  to  accomplish  the  tasks  and  progresses  to 
description  of  program  components.  The  overall  program 
structure  (top-  level)  is  defined,  and  lower-level  compo¬ 
nents  of  the  program  are  defined  in  progressively  increas¬ 
ing  detail. 

Figure  7-2  illustrates  the  organization  of  the  top  level  of 
a  program  developed  for  dredged-material  disposal  manage¬ 
ment.  This  program  consists  of  three  major  computational 
components,  controlled  by  an  executive  routine.  Component 
2.0  reads  the  user's  data  and  manages  it  for  subsequent  use 
by  component  3.0.  The  order  of  input  and  formats  used  are 
defined  by  the  previously  developed  input  guide.  Addition¬ 
al  information,  If  required  for  program  development,  is 
provided  by  additional  diagrams,  as  is  the  case  with  com¬ 
ponent  3.0.  Component  4.0  formulates  and  prints  various 
reports  of  system  operation  and  of  the  efficiency  of  the 
capacity  expansion  options.  The  formats  of  these  reports 
are  established  earlier  with  cooperation  of  potential 
users.  Figure  7-2  also  shows  the  expanded  representation 
of  component  3.0,  presenting  in  more  detail  the  tasks 
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performed  by  this  capacity  expansion  model;  for  convenience 
these  are  identified  as  3.1,  3.2,  and  3.3.  Figure  7-3 
describes  component  3.3  in  more  detail,  with  a  breakdown  of 
the  computations  necessary  to  compute  the  cost  of  a  capaci¬ 
ty  expansion  plan.  The  critical  task  here  is  computation 
of  the  present  value  of  operation  costs. 

7. 3. 4. 3  Specifications .  Each  of  the  components  defined  in 
the  structured  analysis  is  translated  into  one  or  more  sub¬ 
programs  that  perform  independent,  single  tasks.  The  ad¬ 
vantages  of  this  approach  are:  (1)  the  task  of  coding  can 
be  separated;  (2)  complex  programs  can  be  tested  and  veri¬ 
fied  in  parts;  (3)  the  resulting  code  is  easier  to  under¬ 
stand  and  maintain;  (4)  the  resulting  code  is  flexible  and 
can  be  modified  by  changing  single  modules  independently; 
and  (5)  documentation  of  the  code  is  easier.  Items  1  and  2 
are  critical  if  time  constraints  demand  quick  development 
of  production-  grade  programs.  In  such  a  situation,  coding 
and  testing  the  various  modules  can  be  assigned  to  a  number 
of  individuals  who  can  work  simultaneously  and  independent¬ 
ly.  Also  if  budget  constraints  dictate  postponement  of 
development  of  certain  capabilities,  this  also  can  be 
accomplished.  For  example,  development  of  the  previously 
described  dredge  disposal  management  model  was  planned  and 
funded  in  two  stages:  stage  one  included  only  development 
of  a  model  that  would  define  the  minimum-cost  operation 
policy,  while  stage  two  addressed  the  capacity  expansion 
problem  in  detail.  Thus  in  stage  one,  component  3.1  was 
coded  as  a  "dummy"  subroutine,  and  only  a  user-specified 
plan  was  considered.  Nevertheless  the  data  transfers  and 
the  required  results  of  execution  were  defined.  At  the 
completion  of  stage  two,  component  3.1  was  defined  in  more 
detail  and  additional  diagrams  were  developed  to  illustrate 
the  components  required  to  determine  the  next  plan  to  be 
evaluated.  Items  3,  4,  and  5  are  significant  given  the 
environment  within  which  the  computer  code  must  be  used. 
Although  program  development  is  generally  motivated  by  a 
single  application,  other  applications  are  common.  Typi¬ 
cally  these  applications  require  special-case  modifications 
which  must  be  performed  in  the  absence  of  the  original  pro¬ 
gram  designer  or  programer.  If  the  program  code  is  devel¬ 
oped  from  the  structure  diagrams  with  separation  of  the 
components,  modification  or  replacement  of  the  components 
is  easier. 

7.3.5  Detailed  Design  Phase. 

7.3. 5.1  Scope  of  Detail  Design.  The  detail  design  phase 
takes  as  input  the  functional  design  of  the  program 
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components.  The  output  from  the  detail  design  will  show 
how  the  general  descriptions  contained  in  the  functional 
design  will  actually  be  implemented  on  the  computer.  The 
detail  design  must  consider  modularization  of  the  functions 
Into  specific  routines.  It  must  indicate  the  algorithms  to 
be  used  within  the  routine,  as  well  as  internal  communica¬ 
tion  between  itself  and  other  applications  and  systems  rou¬ 
tines  and  external  Interfaces  with  I/O  device  (including 
operators  console,  if  applicable).  All  file  or  data  bases 
used  by  the  program  must  be  specified  and  their  contents 
defined.  This  wilL  greatly  facilitate  system  integration, 
testing  and  maintenance. 

All  global  data  items  necessary  to  carry  out  the  functions 
of  the  program  should  be  identified  and  described.  Global 
data  refers  to  that  data  which  are  required  by  two  or  more 
subroutines  and  can  include  for  example:  constants,  in¬ 
dexes,  flags,  variables  and  tables.  Data  items  should  be 
identified  by  name,  data  types,  values  (extremes  and  nom¬ 
inal),  units  (degrees,  feet/sec.,  etc.)  and  usage  (where 
used,  set).  Additionally,  collective  data  areas  (tables, 
common  blocks,  data  records)  should  be  described. 

7. 3. 5. 2  Detail  Design  Methods.  The  detail  design  must  be 
expressed  in  a  manner  that  clearly  conveys  to  the  programer 
how  each  routine  will  perform.  Several  tools  have  been  ad¬ 
vocated  to  express  the  detail  design  of  a  routine.  Possi¬ 
ble  methods  are; 

a)  English  text  description 

b)  Flow  charts 

c)  Warnier-Orr  diagrams 

d)  Pseudo-code 

e)  combinations  of  above 

The  project  Leader  should  determine  the  method  to  be  used 
for  the  development  of  a  given  program.  The  particular 
method  used  is  not  significant.  What  is  significant  is 
that  the  expression  of  the  detail  design  be  clear,  complete 
and  understandable  by  others  so  that  It  may  be  reviewed, 
implemented,  and  maintained  effectively. 

7. 3. 5. 3  Modularity.  Modularity,  in  this  context,  is 
described  as  the  development  of  interrelated,  individual 
functional  units  which  can  be  Independently  tested.  A 
moduLe  shall  have  a  single  entry  and  exit  point,  thus 
making  the  usage  predictable  each  time  it  is  called. 
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Modularity  Is  achieved  by  dividing  a  program  into  its  func¬ 
tional  component  modules  and  further  dividing  them  into 
smaller  functional  units  as  necessary.  It  must  be  empha¬ 
sized  here  that  the  concept  of  design  by  modular  structure 
is  applicable  at  all  design  levels. 

The  key  characteristics  of  the  modular  approach  is  the  max¬ 
imum  independence  it  affords  one  functional  component  from 
others.  Each  program  component  should  consist  of  a  contig¬ 
uous  group  of  statements  having  a  single  external  identifi¬ 
er  . 


The  necessity  for  modularity  arises  from  a  number  of  fac¬ 
tors  related  to  manageability,  efficiency,  maintainability, 
and  reliability: 

a.  Manageabil ity  is  improved  by  modularity  which  al¬ 
lows  programers  to  implement  and  test  different  pro¬ 
gram  components  in  parallel.  This  permits  many 
programers  to  he  assigned  to  a  single  project,  thus 
shortening  software  development  time. 

b.  Efficiency  is  improved  because  a  function  required 
throughout  the  system  can  be  assigned  to  a  single  pro¬ 
gram  component,  which  is  implemented  and  tested  just 
once.  This  not  only  eliminates  duplication  of  effort, 
but  also  reduces  function  storage  requirements  because 
only  a  single  copy  of  each  function  needs  to  be 
stored . 

c.  Maintainability  is  improved  because  a  modular 
program  is  more  understandable  than  a  monolithic 
program.  Changes  in  a  given  function  are  more  likely 
to  be  localized  to  a  single  function.  Modularity 
improves  the  readability  of  a  program  by  simply 
dealing  with  a  few  lines  of  code. 

d.  Reliability  is  Improved  because  errors  are  more 
Isolated.  Therefore,  they  are  easier  to  pinpoint  and 
correct  and  often  only  affect  the  operation  of  one 
functional  area. 

7.4  Code  Development. 


7.4.1  Allowable  Programing  Languages. 

a.  The  current  standard  for  FORTRAN  is  ANSI  X3. 9-1978 
commonly  known  as  FORTRAN  77.  This  standard  should  be  used 
for  all  newly  developed  programs.  Extensions  to  the  language 
that  <re  offered  should  not  be  used  except  those  directly 
accessing  data  bases  or  communications  devices. 
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b.  Programs  should  be  written  such  that  they  may  be  executed 
on  other  computer  systems  with  a  minimum  amount  of  conversion 
effort.  Limited  use  of  critical  language  features  is  encour¬ 
aged.  (See  Appendix  I.) 

c.  Previously  existing  programs  undergoing  modification  may 
continue  to  be  developed  under  FORTRAN  IV  ANSI  X3. 9-1966, 
using  the  new  standard  where  practical. 

d.  No  use  should  be  made  of  BASIC,  COBOL,  PASCAL,  ADA,  PL1 
or  any  other  language,  without  written  approval  of  the  RCC 
(Figure  7-4 ) . 

e.  For  generalized  programs,  no  assembly  code  routine  or  im¬ 
bedded  assembly  code  should  be  used  in  any  FORTRAN  program  or 
subprogram . 

f.  For  specific  dedicated  programs,  or  communicat ion  rou¬ 
tines,  that  require  assembly  code  programing,  the  assembly 
code  should  be  Isolated  in  a  FORTRAN  callable  subprogram. 

Only  those  functions  actually  requiring  assembly  code  shall 
he  programed  in  assembly  code.  The  RCC  shall  approve  all 
routines  written  in  assembly  code  prior  to  their  development 
' Figure  7-4 )  . 

g.  Code  should  be  written  so  that  programs  can  be  easily 
read  by  individuals  without  extensive  programing  skills. 

7.4.2  Programing  Conventions  and  Standards.  Herein  the  terras 
subprogram,  module  and  routine  are  used  to  refer  collectively  to 
subroutines,  functions  and  block  data  routines. 

7.4. 2.1  Programs.  A  program  consists  of  a  main  program 
and  an  optional  collection  of  subprograms  (i.e.,  subrou¬ 
tines,  functions,  library  routines). 

a.  The  preamble  of  the  main  program  should  contain: 

(1)  Purpose  of  program. 

(2)  Developer  of  program,  address,  phone  number, 
date  . 

(3)  Unit  number  and  purpose  of  all  l/O  units  used 
within  the  program  (indicate  whether  formatted  or 
binary  and  maximum  record  length). 

(4)  Name  and  purpose  of  each  subprogram  used 
within  the  program  (shown  in  alphabetical  order). 


(5;  Routines  calling  each  subroutine. 


(6)  Routines  called  by  each  subroutine. 

(7)  Common  block  location,  length  used,  refer¬ 
enced  by  each  subroutine. 

b.  Arrange  program  code  with  main  program  first, 
blockdata  routine  second;  if  present,  then  all  sub¬ 
programs  in  alphabetical  order. 

c.  The  program  should  contain  one  unlabeled  STOP 
statement  in  the  main  routine  for  normal  program  ter¬ 
mination.  Where  additional  STOP  statements  are  re¬ 
quired  for  termination  of  fatal  error  conditions,  STOP 
statements  with  unique  octal  labels  should  be  used. 

7.4. 2.2  Subprograms .  A  subprogram  is  a  subroutine  or 
function  called  by  a  main  program  or  another  subprogram. 

See  Figure  7-5  for  sample  subroutine. 

a.  The  preamble  to  the  subprogram  should  contain: 

(1)  Purpose  of  subprogram. 

(2)  Name,  address,  phone  number  of  developer. 

(3)  Name  and  definition  of  all  parameters  (in  or¬ 
der  within  subprogram  statement) .  This  should  re¬ 
flect  variable  type,  input/output  parameters  or 
both,  use,  units,  etc. 

(4)  Unit  number  and  purpose  of  all  I/O  units  ref¬ 
erenced  . 

(5)  Name  and  purpose  of  each  subprogram  refer¬ 
enced  . 

(6)  Name  and  purpose  of  each  common  block  refer¬ 
enced  . 

(7)  Original  development  date. 

(8)  Revision  log  containing  for  each  revision: 
the  revision  date,  purpose  of  revision,  and  revi¬ 
sion  author. 

b.  Routines  should  average  about  150  statements 
(about  3  pages)  including  comments  and  should  not  ex¬ 
ceed  250  statements.  As  a  general  rule,  the  smaller 
the  component,  the  easier  it  will  be  to  read,  compre¬ 
hend  and  maintain. 
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c.  Each  subprogram  should  perform  only  one  task. 


d.  There  should  normally  be  only  one  entry  location 
in  a  subprogram. 

e.  There  should  normally  be  only  one  exit  location  in 
a  subprogram. 

f.  Subprograms  should  have  the  responsibility  for 
performing  positive  validation  of  parameters  passed  to 
it.  For  instance  checks  for  type,  range,  sign,  divid¬ 
ing  by  zero  and  exceeding  dimension  limits  should 
always  be  made. 

g.  Where  errors  are  detected  by  a  subprogram,  control 
should  be  returned  to  the  calling  routine  with  the 
error  condition  indicated.  Where  only  the  calling 
routine  has  the  necessary  information  (t.e.,  dimension 

1  limits),  the  calling  routine  should  perform  appropri¬ 

ate  checks  on  parameter  values  before  passing  them  to 
a  subprogram. 

[  h.  Upon  return  from  a  subprogram  the  line  immed  ■' 

following  the  call  should  be  the  next  line  exe< 

Wo  alternative  returns  should  be  used. 

i 

i.  Where  variable  dimensions  arc  used  in  a  subprogram 
the  dimension  limits  should  be  passed  through  the  call 
r  statement  as  parameters. 

|  j .  To  Increase  modularity,  minimize  the  use  of  common 

j  statements  to  pass  operational  parameters.  Data 

should  be  transferred  through  subroutine  arguments  as 
much  as  possible.  Use  common  only  for  passing  limited 
;  control  information,  such  as  a  debug  switch  and  debug 

f  I/O  unit  number. 

[  k.  Functional  duplication  should  be  avoided  when  only 

the  interface  Is  unique.  For  example,  a  single  mathe¬ 
matical  algorithm  should  not  be  embedded  in  more  than 
one  module  when  only  1/0  data  dependency  is  unique. 
Instead,  the  common  single  function  should  be  selected 
|  for  use  with  the  appropriate  interface  routine. 

,  l.  Subroutines  should  not  contain  blocks  of  code 

(more  than  4  or  5  Lines)  which  could  stand  alone  or 
that  could  be  used  by  other  subprograms. 
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7. 4. 2. 3  Subprogram  and  Variable  Names. 

a.  The  name  chosen  for  a  variable  subprogram  should 
be  meaningful  to  its  use. 

b.  Variable  and  subprogram  names  should  not  exceed  6 
characters . 

c.  Temporary  variable  names  should  be  obvious:  TEMP, 
for  example.  Reuse  temporary  names  as  appropriate. 

7. 4. 2. 4  Style  .  This  section  describes  programing 
procedure  requirements  intended  to  provide  consistency  in 
code  development  and  expedite  future  modifications. 

a.  No  assumption  should  be  made  as  to  prior  contents 
of  memory  locations.  Therefore,  all  variables  and 
arrays  should  be  initialized  to  appropriate  values. 

b.  Statement  numbers  should: 

(1)  be  local  to  each  subprogram; 

(2)  increase  from  beginning  to  end  of  routine 
with  increments  of  at  least  10  to  allow  for  future 
inserts;  and 

(3)  be  right  justified  in  columns  2-5. 

c.  No  assumption  should  be  made  as  to  the  relative 
word  length  of  real,  integer  or  other  type  variables. 
An  integer  variable  should  not  be  assumed  to  be  the 
same  word  length  as  a  real. 

d.  Statements  appearing  in  Figure  7-6,  labeled  with  a 
//  sign,  should  be  avoided. 

e.  Real  number  computations  should  contain  no  more 
than  10  significant  digits  and  have  exponents  in  the 
range  of  -30  to  +30. 

f.  Integer  numbers  should  be  in  the  range  of 
-8,000,000  to  +8,000,000. 

g.  Parentheses  and  spaces  that  contribute  to 
readability  should  be  used. 

h.  Calls  to  subprograms  should  be  set  off  by 
appropriate  comment  spacing  for  improved  readability. 


i.  Approximately  25  percent  of  program  source  code 
should  be  comments  clearly  describing  and  documenting 
the  code.  Comments  should  enhance  the  readability  of 
the  code,  and  should  be  structured  within  the  program 
so  that  they  are  readily  seen  by  consistently  begin¬ 
ning  in  a  specific  column  and  by  separation  from  lines 
of  code  with  blank  comment  lines  where  appropriate. 

j.  Comments  should  be  used  to  explain  the  code  so 
that  someone  other  than  the  original  programer  can 
easily  f  tlow  the  program  logic. 

7. 4. 2. 5  Input/Output  (1/0).  This  section  describes  the 
input  and  output  specifications  to  be  applied  during  the 
program  development  phase. 

a.  The  1/0  unit  number  should  appear  In  the  appropri¬ 
ate  statement  as  a  simple  variable  when  reading  or 
writing  data.  For  example: 

MITE  (LINKPK.20)  X ,  Y  ,  X 

b.  Unit  numbers  should  be  In  tile  range  of  11  to  99  to 
enable  easy  program  transportability.  Variables  used 
for  I/O  unit  numbers  should  appear  in  a  separately 
labeled  common  block,  and  should  be  Initialized  In  a 
block  data  subprogram. 

c.  PKI\'T  uul  RKAD  statements  without  a  unit  number 
specified  should  be  avoided.  These  statements  use  de¬ 
fault  uni:  numbers  that  differ  from  machine  to  ma¬ 
chine,  miking  the  results  different  in  various  sys- 

t  ems  . 

1.  Unit  A  should  be  the  default  standard  output  unit 
to  receive  normal  output,  debug  output  and  error 

messages . 

o.  FORMAT  statements  used  more  than  once  should  be 
grouped  together  either  before  the  first  executable 
statement  or  after  the  last  executable  statement  in 
the  routine.  FORMAT  statements  used  only  once  should 
appear  immediately  following  the  I/O  statement  that 
utilizes  it  or  along  with  rauLtiple-use  FORMAT  state¬ 
ments. 

f.  Input  data  should  be  checked  for  validity  at  input 
time.  Invalid  data  should  be  reported  and  processing 
should  continue  wherever  possible.  Where  feasible, 
sep  irate  data  checking  options  should  be  developed  to 
nlnimize  execution  time  for  previously  checked  data 
sets. 
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g.  Standard  width  fields  should  be  used  for  fixed 
format.  Free  format  input  should  be  used  as  much  as 
possible.  Input  should  be  designed  for  ease  of  the 
user,  not  for  ease  of  the  programer.  Input  should  be 
easy  to  proofread. 

h.  On  input  END= ,  branch  should  be  used  for  end  of 
file  detection.  On  input  ERR=,  branch  should  be  used 
for  input  data  error  detection. 

i.  Input  and  output  should  be  localized  in  separate 
subprograms  wherever  possible. 

j.  Internal  I/O  should  be  isolated  in  subprograms 
wherever  possible.  FORTRAN  77  internal  file  using  a 
CHARACTER  variable  should  be  used  in  preference  to 
ENCODE  and  DECODE. 

k.  Output  record  length  for  print  files  normally 
displayed  on  a  line  printer  should  be  up  to  132  char¬ 
acters  including  carriage  control.  Print  file  output 
record  length  for  files  normally  displayed  on  inter¬ 
active  terminal  should  be  up  to  80  characters,  with 
optional  132  characters. 

7. 4. 2. 6  Alphanumeric  Data. 


a.  Alphanumeric  data  variables  should  be  initialized 
only  by  the  DATA  statement  or  READ  statement.  Holler¬ 
ith  specification  (i.e.,  n  H....)  should  appear  only 
in  DATA  statements  or  FORMAT  statements.  It  should 
not  appear  in  CALL,  IF  or  any  other  statements.  DATA 
statements  setting  alphanumeric  data  should  be  of  the 
following  form. 

DIMENSION  INUM  (3) 

DATA  INUM, IB/4H1234.4H3678, 4H90AB , 1HB/ 

b.  The  use  of  single  quotation  marks  (')  to  delimit 
strings  should  be  restricted  to  FORMAT  statements 
only. 
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7. 4. 2. 7  Control  Structure. 

a.  All  newly  developed  programs  should  conform  to  the 

rules  of  structured  programing.  Structured  programs 
not  only  enhance  readability  and  control,  they  sim¬ 
plify  both  the  programing  and  maintenance  functions. 
Structured  programs  use  only  the  five  standard  con¬ 
structs:  SEQUENCE,  IF...  THEN...  ELSE,  DO  WHILE,  DO 

UNTIL  and  CASE.  Unconditional  branching  statements 
(GO  TO)  are  limited  to  instances  where  they  are  needed 
to  implement  one  of  the  above  constructs  and  may  only 
be  used  to  pass  control  forward. 

b.  When  loop  indexes  are  associated  with  dimension 
limits,  variables  should  be  used  for  the  index  lim¬ 
its. 

c.  Flow  of  subprogram  should  be  from  top  to  bottom. 

d.  Checks  for  real  number  equality  in  IF  statements 
should  be  avoided. 

7. 4. 2. 8  Debugging/Error  Messages. 

a.  Debug  messages  should  identify  the  subprogram  and 
location  outputting  the  message. 

b.  Debug  should  nornally  be  controlled  by  variables 
in  a  separate  Trace  and  Debug  control  common  block. 

c.  Debug  messages  should  normally  be  directed  to  I/O 
unit  6. 

a.  Error  messages  should  be  grouped  near  the  end  of 
the  executable  code  of  a  routine,  immediately  prior  to 
the  RETURN  or  STOP  statement.  They  should  also  indi¬ 
cate  the  name  of  the  detecting  routine,  and  nature  of 
the  error. 

7 . 4 . 2 . 4  Specifications  Statements  . 

a.  Specifications  statements  should  occur  in  the 
following  order. 

(1)  Implicit  [i.e.,  IMPLICIT  INTEGER  (A-Z)] 

(2)  Type  (i.e.,  REAL,  INTEGER) 

(3)  Dimension 
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(4)  Common 


(5)  Equivalence 

(6)  External  (i.e.,  EXTERNAL  SIN) 

(7)  Data 

b.  DATA  statements  used  to  initialize  data  In  labeled 
common  blocks  should  be  placed  in  a  separate  block 
data  subprogram. 

c.  The  PARAMETER  statement  must  occur  before  any 
specification  statement  that  makes  reference  to  it. 

The  PARAMETER  statement  should  be  used  to  set  dimen¬ 
sion  limits  and  associated  constants  wherever  possi¬ 
ble  . 

d.  Specifications  that  are  identical  in  several  sub¬ 
programs  should  be  stored  once  and  inserted  into  each 
routine  at  compilation  time. 

7 . 5  Program  Testing . 

7.5.1  Test  Plan.  A  test  plan  should  be  developed  and  should  in¬ 
clude  a  minimum  of  two  test  cases.  One  case  should  use  correct 
input  and  the  other  incorrect  input  data.  Both  test  cases  should 
be  designed  to  test  all  phases  of  the  module.  This  plan  should  be 
included  in  the  preliminary  design  review  (paragraph  7.8.3). 

7.5.2  Individual  Module  Testing.  The  test  cases  should  be  pro¬ 
cessed  by  the  individual  module  prior  to  incorporating  the  module 
into  the  composite  program. 

7.5.3  Composite  Program  Testing.  Upon  successful  completion  of 
the  individual  module  testing,  the  module  should  be  incorporated 
Into  the  composite  program  and  the  test  cases  incorporated  into 
the  composite  test  cases.  The  composite  program  should  then  be 
executed  with  all  composite  test  cases  to  validate  the  Interface. 
The  test  plan,  individual  module  test  results  and  the  composite 
test  results  should  become  part  of  the  final  review  (paragraph 
7.8.6). 


7.5.4  Standard  Test  Data.  A  listing  of  the  correct  composite 
test  case  should  be  included  in  the  user  manual  and  accompany  the 
source  file  during  distribution. 

7 .6  Documentation. 

7.6.1  General .  All  of  the  documentation  as  described  below,  ex¬ 
cluding  charts,  should  be  maintained  within  the  WCDS  and  distri¬ 
buted  along  with  the  program. 
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7.6.2  Development  Documentation.  The  following  documentation 
should  be  maintained  during  the  software  development.  These 
documents  should  be  available  during  the  reviews  as  described  in 
paragraph  7.8. 

a.  Statement  of  Requirements 

b.  Functional  Design  Specifications 

c.  Detailed  Design  Specifications 

d.  Test  Case  Specifications 

This  documentation  should  be  maintained  such  that  it  may  be 
Incorporated  into  the  User  and  Programers'  Manuals  with  very 
little  modification. 

7.6.3  User  Manual.  The  user  manual  is  to  provide  the  user  with 
information  on: 

a.  Purpose  of  program 

b.  Methodology  used 

e.  Capabilities 

d.  Assumptions  and  limitations 

e.  Data  requirements 

f.  Optional  capabilities 

g.  Program  input 

h.  Program  output. 

7.6.4  Programer  Manual.  The  programer  manual  should  include: 

a.  Functional  Design 

b.  Detailed  Design 

c.  Test  Case  Specifications 

d.  Source  Program  listing 

e.  Variable  Definitions 

f.  external  Definitions 
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g.  Variable  Cross-Reference  Usage 

h.  External  Cross-Reference  Usage. 
7 . 7  Program  Maintenance. 


7.7.1  Program  Library.  A  program  library  should  be  maintained  by 
the  Dallas  Site  Manager.  The  library  should  contain  the  following 
items  on  appropriate  media: 

a.  Status  of  all  modules  which  have  been  uniquely  identi¬ 
fied. 

b.  Designer  responsible  for  each  module. 

c.  Statement  of  requirement  for  each  module. 

d.  Program  version  source  module. 

e.  Descriptions  of  module  additions  and  changes  limiting 
program  versions 

f.  Program  variable  cross-reference  listings 

g.  Change  orders  for  each  module 

h.  Uses/Usage  by  lists  for  each  module. 

It  is  anticipated  that  the  program  library  can  be  maintained  on  a 
manual  basis. 

7.7.2  Change  Orders  and  Error  Reports.  Request  for  program 
changes  and  error  reports  should  be  submitted  to  the  Chief  of  the 
SWD  RCC  in  writing.  The  request  should  contain: 

a.  Name  of  module  or  program 

b.  Detailed  description  of  problem  or  requested  change. 

c.  If  an  error  report,  inclose  any  information  that  could 
aid  in  reproducing  or  determining  the  cause  of  the  problem 
such  as  input  being  processed,  error  prints,  core  dumps,  etc. 
The  RCC  and  the  program  developer  should  evaluate  the  request 
as  to  its  impact  on  other  software.  The  request  should  be 
Incorporated  into  the  project  schedule  for  work  assignments. 
The  request  shall  be  incorporated  into  the  software  unit 
file. 

7.7.3  Program  Modification.  The  same  review  guidelines  should 
apply  as  stated  above  for  new  development.  The  following  should 
be  updated  to  reflect  the  modification. 
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a.  Requirements  Statement 

b.  Functional  Design 

c.  Detail  Design 

d.  Coding 

e.  Test  Plan 

f.  Test  Cases 

g.  Users  Manual 

/ 

!..  Programers  Manual 
i.  Software  Unit  File 

The  following  Dallas  program  library  files  should  be  updated  to 
reflect  the  date  of  the  modification,  author  and  nature  of 
mod i float  ion : 

a.  Statement  of  Requirements 

b.  Program  version  source  module 

c.  Description  of  module  additions  and  changes 
J.  Program  variable  cross  reference  listing 

e.  Change  order  file. 

7.8  Review  Process. 

7.8.1  General.  Reviews  are  conducted  to  provide  insights  into 
other  desfgn  and  development  efforts  and  enable  program  developers 
to  interface  with  both  supervisory  and  peer  personnel. 

The  Level  of  review  may  be  Internal  to  the  SWD  RCC,  district 
branch,  district  section,  peer  walkthroughs  or  formal  committee 
depending  on  the  stage  of  development.  The  review  procedures 
relate  to  both  new  programs  modifications  to  existing  programs. 
SmaLl  projects  may  waiver  the  design  and  code  development  review 
steps.  The  review  process  Is  completed  with  the  second  formal 
review.  The  SWD  RCC  should  maintain  a  unit  software  file  of  all 
projects.  Upon  completion  of  a  formal  review  the  head  of  the 
review  panel  shall  forward  a  copy  of  the  review  scheduling  (Figure 
7-7)  and  review  recording  (Figure  7-8)  forms  to  the  Chief  of  the 
SWD  RCC  for  entry  into  the  unit  software  file. 
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In  addition  to  the  reviews  themselves,  the  following  monitoring 
techniques  should  be  applied.  At  least  once  a  month  the  total 
project  plan  should  be  reviewed  by  the  Chief  of  the  SWD  RCC. 
Changes  and  successively  lower  level  definitions  of  detailed 
subtasks  to  be  accomplished  and  related  end  products  should  be 
incorporated.  These  will  be  reflected  in  changes  and  expansions 
to  the  project  milestone  schedules  and  work  assignments.  The 
above  information  (including  the  identification  of  problems  and 
planned  method  of  resolution),  will  fora  the  substance  of  a 
monthly  progress  report  to  the  Chief  of  the  SWD  Water  Management 
Branch  and  all  of  the  District  Branch  Chiefs. 

7.8.2  Small  Project  Review  Procedures.  Special  review  procedures 
for  small  software  development  projects  may  be  requested  by  the 
responsible  District  Section  Chief  at  the  completion  of  the 
Statement  of  Requirements.  Small  projects  are  defined  as  new  or 
revised  tasks  normally  completed  in  two  or  three  person  weeks  of 
effort.  The  abbreviated  review  procedure  requires  only  the  final 
formal  review  step  requesting  acceptance  of  the  completed  project. 
The  request  for  walvering  the  interim  review  steps  should  be  made 
to  the  head  of  the  formal  review  committee.  A  response  is 
required  within  3  working  days. 

7.8.3  Preliminary  Design  Review. 


7.8. 3.1  General . 

The  purpose  of  the  Preliminary  Design  review  is  to  evaluate 
the  basic  design  approach  prior  to  proceeding  with  the 
detailed  design.  The  review  is  conducted  to  determine 
whether  the  design  approach  meets  the  Statement  of 
Requirement  specifications  and  if  all  of  the  interface 
requirements  are  appropriate.  The  review  should  be  held 
when  the  design  has  progressed  to  the  point  where  functions 
have  been  allocated  to  program  modules,  and  operation 
diagrams  are  completed. 

The  review  shall  be  conducted  by  a  "peer  group"  comprised 
of  personnel  outside  of  the  personnel  responsible  for  the 
project.  The  review  personnel  shall  consist  of  one  or  more 
people  familiar  with  the  type  of  study  (project  management 
oriented  knowledge)  and  computer  analyst's  skills.  The 
residing  Head  of  the  formal  review  committee  shall 
designate  the  peer  level  review  constituents.  Detailed 
design  cannot  be  initiated  without  the  concurrence  of  the 
peer  review  group. 

7.8. 3. 2  Review  Information.  The  following  information 
must  be  provided  to  the  reviewers  3  days  prior  to  the 
meeting : 
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a.  A  copy  of  the  Statement  of  Requirements  from  the 
software  unit  file  and  any  proposed  revisions  to  the 
document . 

b.  Structure  "top-down"  design  diagrams  showing  pro¬ 
posed  input,  output,  and  analysis  procedures. 

c.  Preliminary  performance. 

d.  Proposed  testing  procedures. 

7.8. 3. 3  Review  Process  . 

The  review  should  confirm  that  the  presented  computer  pro¬ 
gram  design  satisfies  the  Statement  of  Requirements.  It 
should  uncover  and  resolve  incompatibilities  and  inconsis¬ 
tencies  among  functional  and  physical  interfaces.  The  re¬ 
view  should  also  address  the  test  verification  requirements 
and  any  other  critical  issues  that  ultimately  may  affect 
the  operation  of  the  software.  Detailed  design  may  be  ini¬ 
tiated  after  satisfactory  approval  of  the  "peer"  review 
group. 

The  material  documenting  the  preliminary  design  work  effort 
shall  be  submitted  to  the  Chief  of  the  SWD  RCC  for  inser¬ 
tion  i:  to  the  unit  file  for  the  program.  This  includes  the 
revised  Statement  of  Requirements,  top-down  design  dia¬ 
grams,  and  other  pertinent  text,  notes,  charts,  tables  and 
figures . 

7.8.4  Detailed  Design  Review. 


7. 8. 4.1  General. 

The  detailed  design  review  is  a  technical  review  of  the 
final  software  design  and  draft  documentation  prior  to  ini¬ 
tiation  of  the  coding  and  testing  phases  of  software  devel¬ 
opment.  The  review  is  the  first  of  two  formal  reviews. 

The  review  panel  shall  be  comprised  of  site  personnel  out¬ 
side  the  section  where  the  development  is  occurring.  The 
panel  should  be  familiar  with  the  overall  purpose  and  scope 
of  the  specific  or  similar  project,  and  have  computer  ana¬ 
lysts  and  programing  skills.  The  head  of  the  review  panel 
typically  should  be  of  a  Section  Chief  level.  The  code  de¬ 
velopment  phase  cannot  be  initiated  until  approval  to  do  so 
is  granted  by  the  head  of  the  formal  review  panel. 

7. 8. 4. 2  Review  Information.  The  development  personnel 
shall  provide  the  following  information  to  the  formal  re¬ 
view  panel  at  least  3  days  prior  to  the  scheduled  review 
meeting. 
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a.  The  updated  Statement  of  Requirements  (may  be  part 
of  the  draft  documentation). 

b.  Text,  charts,  schematics,  notes,  etc.  describing 
in  detail  the  design  of  the  program  to  be  implemented. 
This  includes  top-down  structure  design  diagrams  for 
input,  output  and  analysis  procedures.  Psydo-code  may 
be  used  to  detail  each  program  module. 

c.  A  good  working  draft  of  the  programer's  (system) 
and  user's  manuals  should  he  provided.  The  manuals 
shouLd  include  all  aspects  except  final  testing  out¬ 
puts  . 


7. 8. A. 3  Review  Process.  The  review  should  be  of  the  ma¬ 
terial  presented  and  accomplish  the  following: 

a.  Establish  that  the  design  procedures  specified 
satisfies  the  Statement  of  Requirements; 

b.  system  compatibility  exists  by  reviewing  all 
block  diagrams,  schematics,  and  logic  diagrams; 

c.  all  design  changes  specified  during  previous  re¬ 
views  are  met;  and 

d.  proposed  documentation  and  test  procedures  are  to 
the  appropriate  scope  and  focus. 

The  head  of  the  formal  review  panel  shall  submit  all  per¬ 
tinent  materials  to  the  Chief  of  the  SWD  RCC  for  inclusion 
into  the  unit  file  for  the  program.  The  materials  will 
include:  draft  documentat ion  materials,  schematics,  dia¬ 

grams,  and  other  appropriate  materials. 

7.8.5  Code  Development  Peer  Review. 

The  purpose  of  the  peer  review  or  "walkthrough"  of  the  actual 
computer  code  is  to  assure  compatibility  with  the  detailed  design 
specifications  and  the  development  of  the  appropriate  level  and 
quality  of  code.  This  review  should  be  conducted  prior  to  actual 
testing  of  the  program.  In  addition  to  discovery  of  errors  in 
coding,  Interfaces,  and  implementation  specifications  the  peer 
review  also  reduces  supervisory  dependence  on  the  individual  pro¬ 
gramer's  work. 

The  review  panel  shall  consist  of  one  or  more  computer  analysts 
or  programers  outside  of  the  section  responsible  for  the  devel¬ 
opment.  The  reviewers  are  appointed  by  the  head  of  the  formal 
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rev  Lew  panel  and  may  or  may  not  be  part  of  that  panel.  The  re- 
vLewers  shall  submit  a  written  (handwritten)  notice  to  the  head 
of  the  formal  review  panel  when  the  peer  review  is  completed. 

The  message  in  turn  will  be  forwarded  to  the  Chief  of  the  SWD  RCC 
Center  for  inclusion  into  the  unit  tile  for  the  program. 

7.8.6  Final  Review. 

7.8-6. 1  General .  The  final  review  shall  be  conducted  by 
the  formal  review  panel.  It  will  review  all  documenta¬ 
tion,  test  results,  code,  and  the  final  Statement  of  Re¬ 
quirements  to  assure  compliance  with  specified  purposes 
and  objectives.  The  program  is  available  for  distribution 
after  satisfactory  completion  of  this  review. 

7. 8. 6. 2  Information  Presented.  The  following  information 
shall  be  provided  to  the  formal  review  panel  3  days  prior 
to  the  scheduled  review. 

a.  The  unit  file  for  the  program  from  SWD  RCC. 

b.  Revisions  to  Statement  of  Requirements  and  de¬ 
tailed  design  occurring  since  the  previous  formal 
review  session. 

c.  Final  draft  users  and  programer’s  manual  documen¬ 
tation  (5  copies). 

d.  Test  files,  input/output  requirements  and  test 
results . 

7. 8. 6. 3  Review  Process  .  The  formal  review  panel  should 
review  all  documents  to  assure  they  meet  the  software  de¬ 
velopment  guidelines  and  the  overall  SWD  quality  stan¬ 
dards.  A  detailed  review  of  test  results,  inspection  of 
input/output  formats  should  also  be  performed.  After  sat¬ 
isfactory  completion  of  the  review,  the  head  of  the  formal 
review  panel  shall  submit  a  copy  of  the  final  draft  of  the 
Programer  and  User  Manuals  to  the  Chief  of  SWD  RCC  for 
approval  and  Inclusion  in  the  software  unit  file.  The 
unit  file  should  then  be  sent  to  the  Chief  of  the  SWD 
Water  Management  Branch  for  final  approval.  The  software 
unit  file  should  be  returned  to  the  Chief  of  the  SWD  RCC 
for  permanent  filing.  After  final  approval,  the  project 
manager  should  incorporate  the  source  program,  sample  data 
tile  and  documentation  files  into  the  source  program  li¬ 
brary  on  the  Dallas  System  for  distribution. 


SAMPLE  STATEMENT  OF  REQUIREMENTS 


Program:  THEISS 

Statement  ut  Requirements 

1 .  Purpose 

This  program  will  compute  the  basin  iverage  precipitation  for  a 
watershed.  It  is  used  by  engineers  and  hydrologists  to  provide 
precipitation  input  to  hydrologic  models.  A  network  of  up  to 
20  precipitation  stations  may  bo  used  for  any  number  of  time 
per i od  s . 


2.  Capability  Requirements 


a)  The  Theissen  method  for  precipitation  weighting  will  be 
used  . 

b)  A  variable  number  of  precipit  it  ion  stations  up  to  a  maximum 
of  2C  may  be  used. 

c)  Multiple  subbasins  may  be  analyzed. 

d)  There  is  no  lnu1-  to  the  length  of  record  of  the 
precipitation  d  a  t a  . 

e)  All  precipitation  data  will  be  provided  in  the  same  time 
interval . 

f )  A  test  of  3  subbisins,  20  proc i pi  tat  ion  stations  for  2 
years  of  2  hour  but  >  will  be  used. 


3.  Interface  Requirements 

a)  Precipitation  dat  i  may  be  supplied  as  part  of  the  input 
stream,  or  may  be  obtained  alternately  from  an  HECDSS  data 
file. 

b)  Thtissen  factors  for  ,ich  subb.is  in  will  be  provided  as  part 
of  t  he  l  npu  t  str,.  am  . 

c)  Doth  free  for;;;  and  fixed  field  input  will  be  provided. 

d)  Fixed  field  input  will  conform  to  HF,C  standard  - 
A2  ,F6 .0 . ,9F8 .0  -  format. 

e)  Output  will  be  provided  in  80  column  and  132  column  forms 
at  user  option. 

fl  Optionally  input  precipitation  data  may  be  displayed  in  the 
output  file. 

q)  Output  basin  average  precipitation  may  be  tabulated, 

written  to  a  sequential  file  in  HEC-1  precipitation  format, 
or  written  to  HECDSS  file  at  user  option. 


4.  Programming  Requirements 


a)  Tht  program,  must  be  written  for  maximum  transportability. 

b)  Target  systems  include  CDC ,  IBM,  Hnivae,  DEC,  Harris,  Prime 
i  nd  D  a  t  ,|  lie  ne  r  1 1  . 

c)  Ex ecu*  ion  program  s i zo  should  not  exceed  256  K  bytes  for 
d  !  ‘  >  space  and  1 92  K  bytes  for  code  space. 
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SAMPLE  STATEMENT  OF 
REQU I REMENTS 


SAMPLE  SUBROUTINE 


SUBROUTINE  STRMOV  ( I  A , J A , NA , I B , J B ) 


!  PURPOSE:  MOVE  A  STRING  OF  CHARACTERS  FROM  ONE  ARRAY  TO 
ANOTHER 

j  AUTHOR:  JOHN  DOE,  SOUTHWESTERN  DIVISION,  C  OF  E 
I  PHONE:  FTS  222-2222 

I 

i  ORIGINAL  DEVELOPMENT :  FEB.  83 

j 

|  VERSION:  III  -  REVISED  3/10  83 

| 

i  REVISION  LOO:  LOG*STRMOV 


f 

!  I A  -  ARRAY  CONTAINING  STRING  TO  BE  MOVED. 

1  JA  -  STARTING  CHARACTER  POSTION  IN  IA  OF  STRING  TO  BE  MOVED, 
i  NA  -  NUMBER  OF  CHARACTERS  TO  BE  MOVED. 

'  IP  -  ARRAY  INTO  WHICH  MOVED  CHARACTERS  SHOULD  BE  PLACED. 

IB  -  STARTING  CHARACTER  POSTION  IN  IB  AT  WHICH  TO  PLACE 
CHARACTERS 

I 

l  EX  BERNALS  :  GF.TCR  -  GETS  CHARACTER  FROM  IA. 

PUTCR  -  PUTS  CHARACTER  IN  IB. 


***  SET  INTI AL  OUTPUT  POINTER 
. !  = J  B  -  1 

***  SET  LOOP  LIMIT 
NMAX -JA+NA- l 

***  RETURN  IF  NULL  LENGTH  STRING 
IK  (JA  .GT.  NMAX)  GO  TO  10 

***  BEGIN  LOOP  TO  MOVE  ONE  CHARACTER  FROM  IA  AND  PLACE  IN  IB. 

FOR  I  =  .1  A  ,  NMAX 
.1  =.I  •*  I 

CALL  CKTCR  (I  A,  1,1  CII) 

CALL  PUTCR  ( I B , J  ,  I C H 1 

END  KnK 

*  M-'VE  O'MPLETE 

Rl'  i'U  EN 
END 

FIGURE  7 - R 
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FORTRAN  STATEMENTS 
Allowable  Statements  and  forms 

In  describing  the  form  of  FORTRAN  statements,  the  iol towing 
conventions  and  symbols  are  used: 

(1)  Special  characters  from  the  FORTRAN  character  set,  uppercase 
letters,  and  uppercase  words  are  to  be  written  as  shown, 
except,  where  otherwise  noted. 

(21  Lowercase  letters  and  lowercase  words  indicate  general 

entities  for  which  specific  ent:  it  as  must  bo  substituted  in 
actual  statements.  Once  a  given  lowercase  letter  or  word  is 
used  in  a  syntactic  specification  to  -optesent  an  entity,  all 
subsequent  occurrences  of  that  !e‘‘er  or  word  represent  the 
same  entity  until  that  letter  or  word  is  used  in  a  subsequent 
syntactic  specification  to  represent  a  different  entity. 

(3)  Brackets,  [  ),  are  used  to  indicate  optional  items. 

(4)  An  ellipsis,  ...  ,  indicates  that  tire  preceding  optional 

items  may  appear  one  or  more  times  in  succession. 

(5)  Blanks  are  used  to  improve  readability,  but  unless  otherwise 
noted  nave  no  s ig n i f i ca nee . 


s ASSIGN 


*  BACKSPACE  u 

*  BACKSPACE  (all  St) 

BLOCK  DATA  (sub] 

*  BUFFER  IN  (u , iol ist ,name , mode , words , status [, n] ) 

4 BUFFER  OUT  ( u , i o 1 i st , name , mode , word s , s ta t us [, n ) ) 

CALL  sub  |  ( l a  (  , a ]  . . .  1  1  ] 

*  CALL  STATUS  (cilist. ) 

*  CHARACTER  |*len[,]]  nam  |,nam]... 

CLOSE  (cl  list) 

COMMON  [ /  I  cb]  7  ]  nl  i  st  (  [  ,  1  /[cb]/nlist]  ... 

COMPLEX  v  [  .  v 1  .  .  . 

* CONT  I  NUF. 

DATA  nlist/clist  (  (  ,  ]  nl  i st/cl  ist  •']  .  .  . 

*  DATA  P0O[.  /nl  l  st  'cl  i  st  -  11,1  /  n  1  ist:  cl  ist:] 

DIMENSION  n(d)  |  ,  a  ( d )  ]  .  .  . 

DO 


*  DO  s  [  , ]  i =ol ,e2 
DOUBLE  PRECISION 
ELSE 

ELSE  IF  (e>  THEN 
END 

END  FOK 


I  /Oil 


END  I  F 
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*  END  LOOP 
END  WHILE 
ENDFILE  u 
ENDFILE  (alist) 

*  ENTRY  en  (  (  [d  [,d]  ...})) 

EQUIVALENCE  (nlist)  [ , ( nl i st ) ]  .  .  . 

EXIT  DO  [ if (e) ] 

EXIT  IF 

*  E X  I T  LOOP 

FOR  v  =  el , e2  [  ,  e3  ] 

EXTERNAL  proc  | ,proc)  .  .  . 

FORMAT  fs 

fun  ([d  [,d] ...])  =  e 
[type]  FUNCTION  fun  ((d  [,d]...]) 

it  GO  TO  i  [  [  ,  ]  (s  [  ,s]  .  .  .  )  ] 

*GO  TO  s 

GO  TO  (s  [  ,s]  ...)[,  ]  i 

*  I F  (  e)  si ,  s2  ,  s3 

*  I F  (e)  st 
IF  (e)  THEN 

IMPLICIT  typ  (a  [  ,a]  .  .  . ) 

INQUIRE  (iflist) 

INQUIRE  (iulist) 

INTEGER  v  [  , v  3  .  .  . 

INTRINSIC  fun  [  ,  fun]  .  .  . 

LOGICAL  v  [  ,v]  .  .  . 

♦LOOP  [ (p) ] 

OPEN  (olist) 

PARAMETER  (p=e  [,p=e]...) 
it  PAUSE  (n) 

♦PRINT  f  [ , iol ist i 
PROGRAM  pgn 
tf PUNCH  £  [  ,  iol  ist] 

# PUNCH  [ * ]  [  , iol  i  st ] 

-  PUNCH  !-]  i  , iol i st ] 

♦QUADRUPLE  PRECISION  v  [,v . ] 

READ  (cil  ist)  ] 1 o 1 i s  t ] 

♦READ  f  |, iol ist] 

REAL  v  !  ,v]  .  .  . 

*  R ETURN 
REWIND  u 
REWIND  (alist) 

SAVE  [a  ;,a]...] 

♦SPECIAL  COMMON  | nlist  ]  , n 1  l  s  t  .  .  .  .  ]  ] 

STOP  ' n ] 

SUBROUTINE  sub  ](|d  [  ,  d ]  ...])] 

UNTIL  (u) 

V  =  o 
WHILE  ( O ) 

WRITE  ( c l  1  l s  t )  |  l o 1  l S  t ] 

*  Not  :  !  i  OW.-  I 

*  Rf-s  ‘  r  i  1  ■ . i  u so  on  1  y 
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I 'ATE: 


From : 

Cool 

rdi nator : 

S’jb.i : 

Dc  s - 

ign/Code  Review;  Project  Module 

Ref : 

(a) 

Project  Development  Standards ,  Convent: 
Methods  Document. 

Fnei  : 

(1) 

Statement  of  Requirements 

(2) 

Change  Request 

(3) 

Detailed  Design 

(M 

Test.  Cases 

(5; 

Program  Listing  (if  Code  Walkthrough) 

(6) 

Other  references. 

The  subject  review  will  be  held  ae  follows : 
TATE  TIME  DURATION  PLACE 


EErpONSIBILITY 

PRESENTER 

COORDINATOR 

REVIEWER 

REVIEWER 


.i'i  i.- 

as  f\>;  low.:: 

Fv  -v  [ 

•  W  V  f 

Product  by  Pros' 

'onto 

. . . , ; 

"W  *  MV 

Comment,  or.  pro 

iuet 

r 

*  r.v  T»* 

St  Cas.es 

;  .  V'-'lop  Final  A  O. ion  1 , i : - r 
1  ’omp  i ■  !  "  r-’viow  Rec-uv}  Lng  Form 


f 


Hi  v  i  •  w  ing 

Fir  i  re  7-7 


I 

! 


Form 


REVIEW  RECORDING  FORM 


DATE 


PRODUCT  NAME 


INDICATE  TYPE  OF  REVIEW:  PRELIMINARY  DESIGN 

DETAILED  DESIGN 
FINAL 


PARTICIPANTS  RESPONSI BI LITY 

_  PRESENTER 

_  COORDINATOR 

_________________  RECORDER 

_ REV I  EWER 

_ REV  I  EWER 

DECISION:  _ _  accept  product  as  is 

_  revise  (no  further  review) 

_  revised  and  schedule  another  review 

ACTION  LIST:  (identify  actions  by  universal  name,  if  appropriate) 


Review  Recording  Form 
Figure  7-8 


VII £.  SCHEDULE  AND  FUNDING 


8.1  General .  The  development  of  the  SWD  WCDS  to  its  full  design 
capability  will  not  be  complete  until  the  software  described  in 
this  manual  is  developed  and  installed  on  the  system.  The  time  to 
reach  this  design  level  could  range  from  4  to  6  years  depending  on 
the  availability  of  resources.  The  estimated  cost  of  software 
development  for  the  system  is  about  $1.3  million  ($889,000  appli¬ 
cations  and  $460,000  support  software  as  shown  in  Figures  6-1  and 
6-2).  This  represents  about  280  man-months  of  effort.  In  addi¬ 
tion,  the  estimated  manpower  requirements  for  building  the  master 
data  bases  and  the  basin  model  calibration  files  for  the  system 
will  require  between  100  to  150  man-months  of  efforts. 

8.2  Management. 

8.2.1  System  Management.  The  Chief  of  the  SWD  Water  Manage¬ 
ment  Branch  will  coordinate  the  development  of  the  various 
programs/software  which  collectively  form  the  system  of 
software  for  the  WCDS. 

a.  Development  of  Proposals.  The  field  offices 
(districts)  shall  submit  plans  for  development  of  any 
portion  of  the  system  to  the  Chief  of  the  SWD  Water 
Management  Branch  (WMB)  for  review  and  approval  to  pro¬ 
ceed  with  the  project.  The  WMB  shall  review  the  proposal 
to  assure  that  it  is  in  agreement  with  the  system  plan 
and  that  it  has  not  been  prepared  by  some  other  SWD 
district  office.  The  development  will  also  be  coordi¬ 
nated  with  other  divisions  and  HEC. 

b.  Approval  of  Programs  (Software).  After  the  formal 
review  panel  has  reviewed  the  program  as  described  in 
paragraph  7.8.6. 3  a  copy  shall  be  submitted  to  the  Chief 
of  SWD  Water  Management  Branch  for  approval. 

c.  Distribution.  The  Chief  of  SWD  WMB  will  maintain 
copies  of  approved  programs  and  their  documentation  on 
file  for  distribution  to  other  sites  within  the  WCDS. 
These  programs  will  also  be  available  for  exchange  with 
other  Divisions. 

d.  Maintenance  and  Revisions.  All  requests  for  changes 
to  existing  programs  will  be  submitted  to  the  Chief  of 
SWD  WMB.  When  these  are  approved  the  same  proceedures 
and  standards  as  apply  to  a  new  program  will  be  applyed 
to  these  changes.  Approval  and  distribution  of  the  re¬ 
vised  software  will  be  by  the  Chief  of  the  SWD  WMB. 

8.2.2  Software  or  Program  Module  Management.  After  a  field 
office  (district)  development  proposal  is  approved  by  the 
Chief  of  SWD  WMB  the  field  office  will  be  responsible  for 
management  and  review  of  the  module.  The  district  RCC  Branch 
Chief  or  head  of  the  formal  review  panel  shall  assure  that  it 
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conforms  to  the  system  development  standards  and  guidelines  as 
prescribed  in  this  manual.  Formal  reviews  and  submittal  for 
approval  shall  follow  guidelines  set  forth  in  Chapter  7  and 
paragraph  8.2.1 

8 • 3  Schedule . 

8.3.1  General .  The  scheduling  presented  in  this  section  is 
shown  as  priorities  for  development  of  the  applications  soft¬ 
ware  and  support  software.  The  development  has  been  divided 
into  6  priorities.  The  calendar  time  required  for  completion 
of  any  one  priority  and/  entire  system  will  be  dependent  on 
availability  of  resources.  The  applications  software  and 
support  software  development  priorities  are  shown  on  Table 
8-1.  These  are  also  shown  graphically  on  Figures  8-1  through 
8-7. 

8.3.2  Priority  1. 

a.  Priority  1  development  shown  on  Figure  8-1  will 
provide  programs  in  the  Acquisition  Group  (A),  Database 
Utility  Group  (B),  and  Database  Group  (D)  which  are 
necessary  for  entry  and  basic  screening  of  data  from  the 
field  gages  and  observers.  This  will  allow  the  user  to 
assemble  these  data  into  elementary  reports  and  tables. 

At  this  level  of  development,  movement  and  manipulation 
of  the  data  within  the  computer  will  require  considerable 
manual  effort  (interaction)  by  the  user. 

b.  The  development  of  new  and/or  adaptation  of  existing 
software  for  the  SWD  WCDS  as  prooosed  under  priority  1  is 
estimated  to  cost  $268,000.  This  represents  about  56 
man-months  of  effort. 

c.  in  addition  to  the  above  cost  several  man-months  of 
effort  will  be  required  for  development  of  the  Basin 
Model  Files  ( C7 )  and  (C9).  These  files  will  contain  the 
calibration  data  for  each  river  basin,  watershed,  or 
project  where  the  forecast  and  operation  models  are  to  be 
applied.  The  cost  of  developing  these  calibration  files 
could  range  from  $25,000  to  $50,000  per  basin  for  the 
streamflow  forecast  model  (C2)  and  from  $10,000  to 
$20,000  per  basin  for  the  operation  model.  The  cost  per 
basin  will  vary  depending  on  the  amount  of  prior  work 
that  has  been  done  on  developing  hydrographs,  routing 
coefficients,  etc.  This  effort  can  begin  at  priority  1 
and  continue  as  resources  are  available.  C7  files  should 
be  complete  when  priority  4  is  reached  and  C9  files 
should  be  complete  when  priority  5  is  reached. 

8.3.3  Priority  2.  The  priority  2  development  shown  on  Figure  8-2 
will  provide  enhancement  of  the  acquisition  and  editing  of  data. 

The  software  proposed  under  priority  2  is  estimated  to  cost 
$265,000  and  represents  55  man-months  of  effort. 
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8.3.4  Priority  3.  The  priority  3  development  shown  on  Figure  8-3 
provides  for  graphical  display,  enhancement  of  data  analysis  and 
screening,  and  the  streamflou  forecast  model.  The  software 
proposed  under  priority  3  is  estimated  to  cost  $214,000  and 
represents  45  man-months  of  effort. 

8.3.5  Priority  4.  The  priority  4  development  shown  on  Figure  8-4 
would  provide  stream  flow  forecasts,  additional  reports,  gate 
setting  outflow,  and  improved  system  operation.  This  software  is 
estimated  to  cost  $190,000  and  represents  39  man-months  of  effort. 

8.3.6  Priority  5.  The  priority  5  development  shown  on  Figure  8-5 
will  provide  for  operations  models,  economic  and  extended  analysis 
general  archiving  and  a  data  network,  link,  for  transfer  of  data 
through  the  system.  This  software  is  estimated  to  cost  $207,000 
and  represents  43  man-months  of  effort. 

8.3.7  Priority  6.  The  priority  6  development  shown  on  Figure  8-6 
provides  for  an  enhancement  of  data  acquisition  by  adding  programs 
for  collecting  satellite  and  radar  imagery  data  completing  analysis 
and  support  software.  This  software  is  estimated  to  cost  $205,000 
and  represents  42  man-months  of  effort. 

8.3.8  Support  Software.  The  support  software  shown  on  Figure  8-7 
should  be  developed  concurrently  with  the  applications  software  in 
order  to  provide  "a  user  friendly  system."  The  proposed  priorities 
for  this  development  are  shown  on  table  8-1.  Support  software 

i no lude  s : 


a.  The  Database  Routines. 

b.  The  Control  Routines. 

c.  Ttie  Records  Routines. 

d.  Tiie  Commun  icat  ions  support. 

e.  The  Training  Aids. 
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TABLE  8-1 

SYSTEM  DEVELOPMENT  COST  i»  PRIORITIES  shout 
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8.4  Summary  of  Resource  Requirements.  The  following  tabulation 
gives  a  summary  of  the  estimated  resource  requirements  for  develop¬ 
ment  of  the  SWD  WCDS: 


TABLE  8-2 
COST  SUMMARY 


Priority 

1 - 

| 

,  $1,000 

Equivalent 

Manpower 

(Man-months) 

Applications 

Software 

| 

Support 

Sof  tuare 

Total 

1 

108 

160 

268 

56 

2 

215 

i 

50 

265 

55 

3 

114 

100 

214 

1 

45 

4 

105 

1 

1 

85 

i 

190 

39 

5 

|  192 

n  : 

207  ! 

i  1 

43 

6 

155 

50 

1  i 

205  | 

42 

889 

460  | 

1  j 

1,349  | 

280 

TOTAL 


NOTE.  Building  master  data  base  (Dl)  and  calibration  of  basin 

models  (C7  &  C9)  may  require  an  additional  190  to  210  man- 
months.  These  costs  have  not  been  included  in  the  above 
f  tgures . 
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IX.  Glossary. 


Applications  Program:  A  routine  or  set  of  routines  performing  a  spe¬ 
cific  function(s)  of  the  user's  entire  job. 

Asynchronous:  Events  which  possess  no  common  time  relationship;  i.e., 

they  occur  independently. 

Batch  Processing:  The  technique  of  executing  a  set  of  computer  pro¬ 
grams  such  that  each  is  completed  before  the  next  program  of  the  set  is 
started . 

Bottom-up  programing:  Programing  activities  which  start  at  the  specif¬ 
ic  or  detailed  level  of  a  system  and  work  toward  the  more  abstrac  , 
fund  tonal  level  of  a  system. 

CALL:  The  command  which  executes  a  procedure. 


Checkpoint:  A  point  it  which  information  about  the  status  of  a  job  can 

be  recorded. 

Data  Base:  Sequential,  hiorarcht.il,  or  network  organization  of  data 
fundamental  to  in  enterprise.  May  be  more  than  one  related  data  set 
(fife)  . 

Data  base  Management  System:  The  entire  set  of  procedures  and  programs 
designed  to  control  a  data  pool  which  is  created  to  provide  centraliza¬ 
tion,  reliability  and  ease  of  accessibility  and  maintainability  of 
data.  Ultimately,  the  purpose  of  providing  a  data  base  management  sys¬ 
tem  is  to  increase  throughput  and  shorten  turn-around  times  of  the  as¬ 
sociated  computer  system. 

Data  E ' oraent :  An  identifiable,  accessible  data  Item  or  group  of  data 
items  (e.g  a  customer's  complete  address).  Data  items  which  are  col¬ 
lectively  identified  as  data  elements  are  accessed  collectively  and 
cannot  be  access  individually. 

'Lata  Kite:  An  organized,  identifiable,  accessible  group  of  data  rec¬ 
ords  . 

Data  Item:  The  smallest  identifiable  and/or  accessible  data  entity. 

Data  Record:  An  organized,  identifiable,  accessible  group  of  data 
items  and/or  data  elements. 

Data  Set:  Any  Logical  input/output  entity  such,  as  a  terminal,  terminal 
message,  data  file,  record  or  byte  string.  A  major  unit  of  data  stor¬ 
age  and  retrieval,  consisting,  of  a  collection  of  data  in  one  of  several 
pre-dose  r  i  bed  arrangements.  L'sed  1  nlerchangeubly  with  file  or  data 
file. 


Data  Structured  Systems  Development:  A  practical,  proven  approach  to 
software  development  that  covers  planning,  requirements  definitions, 
system/data  base  design,  programing  and  project  management.  A  total 
system  Life  cycle  approach  to  software  development  based  on  data  struc¬ 
ture  . 


Environment:  All  of  the  relevant  factors  which  affect  the  operations 

of  a  program  or  system.  Some  areas  normally  considered  a  part  of  the 
environment  are  the  operating  systems,  CPU,  channel  and  device  config¬ 
urations,  teleprocessing  network,  and  other  programs  or  tasks  operating 
within  the  same  processing  unit. 

Heuristic:  Trial  and  error. 

implementation:  Those  stages  of  program  development  including  coding, 

testing  and  system  Integration. 

Interactive:  Programs  requiring  user  interaction  during  execution. 


Job  Control  Language:  A  set  of  controls  used  to  direct  the  execution 
of  computer  programs. 

Link:  (1)  A  logical  interconnection  between  files. 

(2)  Object  programs  to  be  incorporated  to  form  a  load  module. 

Linkage  Path:  A  path  or  direction  which  must  be  followed  in  order  to 
access  one  or  more  specific  ecords  in  a  variable  record  chain. 

Load  ModuLe:  A  module  in  ^  format  suitables  for  loading  Into  main 
storage  by  the  control  program. 

Logical  Head:  The  acquisition  of  a  data  record  from  an  input,  output 
butter. 

Logical  Record:  A  subset  of  a  physical  record. 

Logical  Write:  The  transfer  ot  data  from  working  storage  to  an 
i nput / out  put  buffer. 

Module:  A  sot  of  computer  instructions  which  perform  a  limited  func¬ 

tion.  Normally  does  not  stand  alone.  Used  interchangeably  with  rou- 

t  i  tie  . 

Mu  1 1 i- processing :  Pertains  to  the  simultaneous  execution  f  two  or 
note  computer  programs  or  sequences  of  instructions  by  a  computer.  A 
computer  svstem  employing  two  or  more  Interconnected  processing  units 
to  execute  programs  simultaneously. 

Mult i- programing:  Pertains  to  the  concurrent  execution  ot  two  or  more 
pt'ogr  tin  by  a  computer.  A  computer  system  which  can  process  two  or  more 
;  r  'grins  concurrent  1 v  by  interlacing  their  execution. 
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Multi-tasking:  Concurrent  execution  ot  more  than  one  task.  The  tasks 

may  either  multi-thread  through  a  single  program  or  single- thread 
through  multiple  programs  or  a  combination  ot  both. 

Mu  1 1 i- thread :  Pertains  to  the  concurrent  execution  of  a  re-entrant 
program  by  more  than  on  task.  Each  task  may  take  different  threads 
through  the  same  program. 

Object  Program:  A  machine  language  program  which  is  the  output  after 
translation  from  the  source  program. 

Operating  System:  Software  which  controls  the  execution  of  computer 
programs  and  watch  may  provide  scheduling,  debugging,  input/output 
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Random  Processing:  The  treatment  of  data  without  respect  to  its 
location  in  external  storage,  and  in  arbltary  sequence  governed  by  the 
input  against  which  it  is  to  be  processed. 

Real  Time:  (i)  Executed  according  to  clock  or  calendar  time. 

(2)  Actions  which  affect  a  positive  influence  on  the 
environment . 

Routines:  See  module. 

Source  Program:  A  series  of  statements  in  the  symbolic  language  of  the 
assembler  that  is  input  to  the  translation  process. 

Structured  Programing:  A  set  of  rules  for  programing  which  restrict 
program  development  and  maintenance  to  a  few  techniques  which  result  in 
a  well-ordered,  eaisly  readable,  and  verifiable  and  maintainable 
program. 

Subroutine:  A  subprogram  which  cannot  stand  alone,  it  must  be  called 
by  a  program. 

Synchronous:  Occuring  at  a  pre-established  rate  or  running  off  the 
same  clock. 

System:  (1)  General  Definition:  An  ordered  set  of  elements  organized 
toward  the  achievement  of  a  common  goal  or  set  of  goals. 

(2)  Program  Context  Definition:  A  group  of  applications 
programs  which  cooperate  in  the  production  of  a  single  product 
or  a  set  of  products. 

System  Integration:  The  combining  of  two  or  more  programs  into  the 
operational  system. 

Throughput:  Total  volume  of  work  performed  by  a  computing  system  over 
a  given  period  of  time. 

Time-sharing:  Sharing  of  CPU  among  more  than  one  user  to  produce  the 
appearance  that  each  user  has  sole  use  of  the  computer  system. 

Top-down  Programing:  Programing  activities  which  start  with  the  most 
abstract  or  general  function  of  a  system  and  work  toward  the  more 
specific  functions  and  activities  of  a  system. 

Variable:  A  numeric  or  character  value  which  changes  as  dictated  by 
the  related  program. 

Version:  A  program  which  performs  a  part  of  the  total  function 
required  of  the  complete  program. 
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